В какой библиотеке можно писать GUI

кстати, а есть у кого-нибудь сравнение по скорости линковки и качеству LTO между msvc и clang?

Не думаю, что LLVM может делать лучше, чем компилятор от создателей компиляторов с 1978 года.

Не думаю, что LLVM может делать лучше, чем компилятор от создателей компиляторов с 1978 года.

?

В какой библиотеке можно писать GUI

Бери Qt и в @qt_chat.

Не думаю, что LLVM может делать лучше, чем компилятор от создателей компиляторов с 1978 года.

это ты серьёзно?

Бери Qt и в @qt_chat.

?

это ты серьёзно?

тролирует видимо

Не думаю, что LLVM может делать лучше, чем компилятор от создателей компиляторов с 1978 года.

Слишком толсто. Устное предупреждение. Нужно быть тоньше.

А еще, насколько помню, лучшие оптимизации были у компилятора от Интел.

А еще, насколько помню, лучшие оптимизации были у компилятора от Интел.

it depends

А еще, насколько помню, лучшие оптимизации были у компилятора от Интел.

разве что оптимизация числодробилок и только под инструкции интела)

меня конкретно интересует LTO и особенности работы линковщика

недавно товарищ хоторый занимается HPC, поведал что icc не сильно то лучше gcc, а то и хуже местами

недавно товарищ хоторый занимается HPC, поведал что icc не сильно то лучше gcc, а то и хуже местами

и это истинная правда

только вот если говорим про оптимизацию под самые свежие процы, то icc получше бывает намного

а ещё кланг пока сливает им обоим, и это тоже правда

потому что в него завозят быстрее поддержку свежих инструкций

а ещё кланг пока сливает им обоим, и это тоже правда

истинно так

ну да, а ещё никто кроме MS не запилил Parallel TS

и это меня огорчает

Intel вроде засылал это дело в libstdc++/;ibc++

и емнип в репе llvm я видел кодяру parallel stl

вроде да, но я по статусу пробегал, даже намёков нет на прогресс

только я её пока что не смотрел

и FS до сих пор в libcxx нет

Не думаю, что LLVM может делать лучше, чем компилятор от создателей компиляторов с 1978 года.

Ничё, что сейчас этот самый LLVM встроен частично в компилятор этих самых что с 1978?

А еще, насколько помню, лучшие оптимизации были у компилятора от Интел.

Именно. Лучшие. Только ... только под интел.

недавно товарищ хоторый занимается HPC, поведал что icc не сильно то лучше gcc, а то и хуже местами

Ну это вообще очень сложный вопрос.. где-то лучше, где-то хуже...

Вот я и провел аналогию, что чем меньше у компилятора/линковщика фронтэндов и бэкэндов, тем он эффективнее.

Релизнулся Conan 1.8! https://docs.conan.io/en/latest/changelog.html

#goodNewsEveryOne

1.8.1 релизнулся с фиксами

и CPT новый

Народ, а по какой причине вот такой код не работает: https://godbolt.org/z/J_1Lif А вот такой код работает?: https://godbolt.org/z/D0mXLx

Народ, а по какой причине вот такой код не работает: https://godbolt.org/z/J_1Lif А вот такой код работает?: https://godbolt.org/z/D0mXLx

Там есть правило что if constexpr не отменяет требования синтаксической корректности

Там есть правило что if constexpr не отменяет требования синтаксической корректности

Получается, что наличие реализации\объявления функции - это требование синтаксической корректности?

obj.badMethod() проходит попытку overload resolution и неожиданно находит 0

(Да, во втором примере - ошибся. Вот правильный вариант: https://godbolt.org/z/C6xzr1)

Получается, что наличие реализации\объявления функции - это требование синтаксической корректности?

Нет, конструкция, выглядящая как вызов несуществующей функции - синтаксическая ошибка

Нет, конструкция, выглядящая как вызов несуществующей функции - синтаксическая ошибка

Вот, понял. Спасибо.

Вот, понял. Спасибо.

В случае (2) такого не происходит, поскольку конструкция, использующая зависимое имя, не является синтаксической ошибкой, пока не установлено имя

В случае (2) такого не происходит, поскольку конструкция, использующая зависимое имя, не является синтаксической ошибкой, пока не установлено имя

Да, значит я правильно понял. Опять же, спасибо.

Да, значит я правильно понял. Опять же, спасибо.

Ну там реализационно компилятор останавливается на точке, где ему необходимо знать, что скрывается за зависимым именем, и продолжает уже при инстанцировании. Там будут забавные тонкости https://godbolt.org/z/f-4yyA

Ну там реализационно компилятор останавливается на точке, где ему необходимо знать, что скрывается за зависимым именем, и продолжает уже при инстанцировании. Там будут забавные тонкости https://godbolt.org/z/f-4yyA

Хм, да, действительно забавно получается. Достаточно убрать obj из вызова - и вот, уже невалидно

Хм, да, действительно забавно получается. Достаточно убрать obj из вызова - и вот, уже невалидно

Достаточно указать namespace (т.е. сделать qualified name) и уже невалидно

Потому что компилятору не нужно теперь производить ADL, который зависит от типа параметра

Достаточно указать namespace (т.е. сделать qualified name) и уже невалидно

Да уж, интересные тонкости. Их можно прикладывать в качестве ответа на вопрос об изучении C++ за 21 день\месяц\год

Да уж, интересные тонкости. Их можно прикладывать в качестве ответа на вопрос об изучении C++ за 21 день\месяц\год

Я использую код std::apply (вроде, объяснение её реализации займет как раз 21 день)

Я использую код std::apply (вроде, объяснение её реализации займет как раз 21 день)

химичил я что-то с вариадиками, другое, третье, в итоге через апплай работают только не cv, реф типы

только по значению

По sigkill стек же не разматывается?

То есть в boost::unique_lock глупо оборачивать boost interporcess named_mutex?

По sigkill стек же не разматывается?

нет конечно

по sigterm можно инициировать раскрутку, но это довольно сложно

по sigterm можно инициировать раскрутку, но это довольно сложно

То есть по sigbus, sigsegv тоже беда? Понятно, спасибо

То есть в boost::unique_lock глупо оборачивать boost interporcess named_mutex?

А там нет гарантий? Всякие шиндоус выдадут abandon на блокировку

есть немаскируемые сигналы

ещё sigstop и sigfpu нельзя перехватить

вернее sigbus, sisegv и sigfpu можно, но смысл?

вернее sigbus, sisegv и sigfpu можно, но смысл?

Вывести стектрейс перед падением. Можно настроить чтобы coredump'ы откладывались, но они бывают большие, а стектрейса часто достаточно.

Вывести стектрейс перед падением. Можно настроить чтобы coredump'ы откладывались, но они бывают большие, а стектрейса часто достаточно.

Какого из потоков, если их несколько?

А если дебажной инфы нет?

А там нет гарантий? Всякие шиндоус выдадут abandon на блокировку

Boost unique_lock не из boost interprocess, я в чужом коде увидел как boost interprocess named_mutex лочится с помощью boost unique_lock

Boost unique_lock не из boost interprocess, я в чужом коде увидел как boost interprocess named_mutex лочится с помощью boost unique_lock

Я ваш вопрос не понимаю, в части неожиданного провала программы там же гарантии ОС

Я ваш вопрос не понимаю, в части неожиданного провала программы там же гарантии ОС

Не-а, named_mutex будет в залоченном состоянии

Его никто не разлочит, если залочевший упал

Если реализация posix , то 100%

Если реализация posix , то 100%

Плохо работать с вашей системой %)

Плохо работать с вашей системой %)

Да не, норм, можно удалить, но разлочить не получится (:

Какого из потоков, если их несколько?

(Того, который вызвал segmentation fault. Нет отладочных символов — вывести хотя бы адреса.) При чём тут «если»? Я отвечал на вопрос о том, какой смысл может быть в некоторых ситуациях у перехватывания SIGSEGV.

То есть по sigbus, sigsegv тоже беда? Понятно, спасибо

https://www.boost.org/doc/libs/1_65_1/doc/html/stacktrace.html

c sigkill не сработает, разумеется.

c sigkill не сработает, разумеется.

Ну это понятно, спасибо

а точно сегфолт вызвал определённый поток?

сегфолт может вызвать например обработчик сигнала, если на момент его вызова стек почти исчерпался, а обработчику уже не хватило

можно резервный стек под такие вещи правда делать

а точно сегфолт вызвал определённый поток?

Вроде бы да, кстати, сигнал в линуксах хоть извне, хоть изнутри, но присылается именно потоку. Доиграться до SIGSGV в обработчике SIGSEGV — это, конечно, успех. Я так делал. (А в какой-то раз даже специально: пошерстить память при падении, при том что каждое чтение может пофейлиться.) А без альтстека вообще типичная ситуация.

Вроде бы да, кстати, сигнал в линуксах хоть извне, хоть изнутри, но присылается именно потоку. Доиграться до SIGSGV в обработчике SIGSEGV — это, конечно, успех. Я так делал. (А в какой-то раз даже специально: пошерстить память при падении, при том что каждое чтение может пофейлиться.) А без альтстека вообще типичная ситуация.

Да, потоку, но отсутствие обработки сигнала в потоке std::thread приведёт к std::terminate так что выглядит на вскидку как будто процессу пришёл сигнал.

Вроде бы да, кстати, сигнал в линуксах хоть извне, хоть изнутри, но присылается именно потоку. Доиграться до SIGSGV в обработчике SIGSEGV — это, конечно, успех. Я так делал. (А в какой-то раз даже специально: пошерстить память при падении, при том что каждое чтение может пофейлиться.) А без альтстека вообще типичная ситуация.

сигнал потоку?

сигнал потоку?

Ну не то, чтобы это сильное противоречие, поток же к процессу относится