Ок. Хочу пример когда сишный интерфейс пострадает от ABI совместимости

Изменение function call convention. Изменение именования функций. Было уже 20 раз

Изменение function call convention. Изменение именования функций. Было уже 20 раз

Function call convention на 64-бит системах один. Раньше он был частью типа функции - т.е. если ты cdecl позвал как stdcall - ссзб. Что такое изменение именования функций вообще не понял. Манглинга нету, а простое переименование относится к ABI как слон к балерине.

Microsoft например добавлял впереди _. Плюс lover case upper case.

И до сих пор добавляет, правда? При этом есть .def файл, в котором можно имена указать как захочешь. ABI совместимость это не трогает. ABI совместимость между платформами не существует, потом пофигу что там добавляет msvc, пока он это добавляет всегда и это документировано. Проблемы с ABI это, например, когда ты на той же платформе берешь компилятор посвежей и ничего не меняя в коде просто компилируешь новый бинарь, и после этого клиенты, которые правильно работали со старой версией отваливаются нафиг

Увы, если подразумеваемой тобой хернёй не страдать, проблем будет ещё больше, чем если страдать

Name mangling, конечно, никто никогда менять не будет (хотя это и не гарантируется Microsoft'ом), но, скажем, в VS2017 в С++ поменялся layout классов с несколькими пустыми базами, поэтому для обратной совместимости даже ввели __declspec(layout_version(19)). Для C layout структур не менялся и никогда не будет меняться.

Господа, прошу помощи в личку. Суть - не могу настроить сборку проекта.

cmake тут

https://pastebin.ubuntu.com/p/vvTr7TmdD4/

структура проекта: /src/main.cpp /src/statemachine.cpp /include/statemachine.hpp /include/state.hpp /include/DEFINITIONS.h /build CMakeList.txt собирать пытаюсь из build

на этапе линковки получаю

/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib/Scrt1.o: in function `_start': (.text+0x24): undefined reference to `main'

ранее это был проект с sfml, я повырезал из cmakelist всё лишнее, но может как-то криво повырезал, уже часа два бьюсь

или с благодарностью приму в дар рабочий "универсальный" cmakelist для небольших проектов

/usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../lib/Scrt1.o: in function `_start': (.text+0x24): undefined reference to `main'

Линкер не находит функцию main. Похоже что у тебя main.cpp не добавлен в список файлов на компиляцию.

[ 33%] Building CXX object CMakeFiles/pocketdung.dir/src/main.cpp.o [ 66%] Building CXX object CMakeFiles/pocketdung.dir/src/statemachine.cpp.o

после этого ошибка

до линкера дошло, все (а их целых ДВА) файла проекта скомпилились перед этим

Включи verbose mode и посмотри какие обьектники линкеру передаются. Функция main у тебя есть?

никто не встречал на винде, что SetUnhandledExceptionFilter не вызывается из std::thread, т.к. они noexcept?

никто не встречал на винде, что SetUnhandledExceptionFilter не вызывается из std::thread, т.к. они noexcept?

я не понял вопрос

в main() ставим SetUnhandledExceptionFilter, далее std::thread t([] { throw 5; });, наш обработчик не вызовется, вместо него будет терминейт, т.к. std::thread помечен, как noexcept и он не даёт вызвать хендлер

Щас бы эксепшоны из тредов ловить в другом потоке

В 2к18

хм... так отдельные потоки изолированы по исключениям

получается даже по SEH

SEH это не про throw 5; я полагаю

мне минидамп надо сделать, а там terminate()

так terminate вызван обработчиком

вообще там обертки с catch-ем есть для промизов

нет, он компилятором впихивается из-за noexcept

да, но исключение было обработано

т.е. CreateThread будет работать так, а std::thread уже нет

What's happening here is that std::thread is defined as noexcept which enforces termination if an unhandled exception propagates out of it. As such, the throw inside the thread should never have propagated out and the handler set in SetUnhandledExceptionFilter shouldn't have been invoked in any case. To catch this scenario, use set_terminate in addition to SetUnhandledExceptionFilter.

https://developercommunity.visualstudio.com/content/problem/235602/setunhandledexceptionfilter-callback-not-invoked-f.html

вы же понимаете, что исключение до UnhandledExceptionFilter вообще не дошло?

мне минидамп надо сделать, а там terminate()

https://en.cppreference.com/w/cpp/error/set_terminate

Вот можно попробовать

вы же понимаете, что исключение до UnhandledExceptionFilter вообще не дошло?

и я об этом

set_terminate уже начал делать

но в set_terminate я уже не могу получить исключение, компилятор пишет: error C2707: '_exception_info': bad context for intrinsic function note: _exception_info() outside an exception filter

так поймайте его кек

ну для каждой std::thread обёртку придётся делать

ну для каждой std::thread обёртку придётся делать

Так и надо

видимо, включая SEH

а вы собираетесь SEH в лицо получать?

там, вроде, даже под /EHsc это черевато

а куда его ещё получать?

SEH не должно триггериться

ну вот в минидампе посмотрю и исправлю, где вылезло

если у вас pagefault падает в область вне вашей памяти, то вы уже совершенно точно в UB области плюсов

да я и хотел бы винапи хендлер в этом месте и минидамп

ну так не запускайте бросающие исключения потоки просто так)

всякие promise-ы в этом случае exception_ptr через потоки таскают

да мало ли кто, какая библиотека что создаст и что кинет, тут общий подход от системы рубится ноексептом

а если какая библиотека вызовет _exit

всё в порядке, хочу видеть краши

_exit это по сути ::ExitProcess без всего

подходит

если библиотека работает не как надо - вопрос к авторам библиотеки

само собой

проверил SEH из std::thread обрабатываются SetUnhandledExceptionFilter, тогда всё более менее

Подскажите, пожалуйста, тезисно: почему std::bind или boost::bind хуже чем использование лямбд?

Подскажите, пожалуйста, тезисно: почему std::bind или boost::bind хуже чем использование лямбд?

А что такое boost::?

Это типа библиотека такая?

Случаем не для Serialization?

Это типа библиотека такая?

лол да

Это типа библиотека такая?

Это больше чем библиотека

одна из самых известных для плюсов

Это больше чем библиотека

о да

Она выглядит бесконечной

Негласный плюсовый стандарт

Подскажите, пожалуйста, тезисно: почему std::bind или boost::bind хуже чем использование лямбд?

Тезисно -- потому что bind медленнее. Он тянет за собой аллокации памяти и лишает компилятор возможности соптимизировать вызов. В то время как лямбда занимает просто один прямой вызов, и может даже и просто заинлайниться.

Тезисно -- потому что bind медленнее. Он тянет за собой аллокации памяти и лишает компилятор возможности соптимизировать вызов. В то время как лямбда занимает просто один прямой вызов, и может даже и просто заинлайниться.

Спасибо

Тезисно -- потому что bind медленнее. Он тянет за собой аллокации памяти и лишает компилятор возможности соптимизировать вызов. В то время как лямбда занимает просто один прямой вызов, и может даже и просто заинлайниться.

А [x=big_thing, v=vector]{ /* some code */ } Не будет тянуть разве аллокации ?

Это больше чем библиотека

Как работать в ней с Serialization? А-то не знаю где там туториалы по ней искать или типа того, для собственного движка 2D игры

Как работать в ней с Serialization? А-то не знаю где там туториалы по ней искать или типа того, для собственного движка 2D игры

boost org documentation поищи

Как работать в ней с Serialization? А-то не знаю где там туториалы по ней искать или типа того, для собственного движка 2D игры

boost boris schaling книга ещё может помочь

А [x=big_thing, v=vector]{ /* some code */ } Не будет тянуть разве аллокации ?

Безусловно, будет. Так же как и вызов функции с такой сигнатурой. Стоит рассмотреть возможность передавать это по ссылке. Только bind сделает ещё и свои дополнительные аллокации.

Подскажите, пожалуйста, тезисно: почему std::bind или boost::bind хуже чем использование лямбд?

У bind просто читаемость сильно хуже. Большинство вещей для которых юзают bind, можно сделать через лямбду.

boost::asio::async_write( m_socket, boost::asio::buffer(m_pending_sends.front()), boost::asio::bind_executor( m_io_strand, [ self=shared_from_this(), send_buffer_it=m_pending_sends.begin() ] (auto &&ec, auto &&...) { self->HandleSend(ec,send_buffer_it); } ) ); А такая лямбда лишних аллокаций динамических не должна добавлять?

У bind просто читаемость сильно хуже. Большинство вещей для которых юзают bind, можно сделать через лямбду.

Там по-моему как раз производительность ужс

Ща

https://www.youtube.com/watch?v=JtUZmkvroKg

https://www.youtube.com/watch?v=JtUZmkvroKg

В этом видео нет про производительность(:

В этом видео нет про производительность(:

Хм, странно, вроде это было оно

Может быть в том, что назвается the cost of lambdas

Негласный плюсовый стандарт

Слишком жирно.

Слишком жирно.

Скорее площадка для подготовки технических спецификаций новых стандартов и иногда качественные готовые решения

Господа

А вот кто знает