так, к очередному раунду битвы я тоже не готов)) это напотом можно оставить

Засчёт этого С++ быстрый, да

Да не сильно быстрее чем без этого

У тебя и замеры есть, да?

А то так непонятно? Если просто все ub перевести в id то окажется очень нпмного случаев когда такая оптимизация дает выйгрышь, причем на современных архитектурах - выйгрышь минимальный, на фоне всей программы - вообще незаметный. Но ты можешь опроверг меня кодом, это проще чем наоборот

У меня складывается ощущение, что это решение, которое потребует позже решать проблемы этого решения...

Имхо, проблема производительности — не самое страшное лично для меня, хуже в исключениях то, что когда ты работаешь с кодом, кидающим исключения, тебе нужно обкладываться try/catch на каждый чих, увеличивая цикломатическую сложность кода и каждый раз ожидать, что где-то что-то поймал не там, где было нужно. Добавляя кучу разных способов кидать и ловить исключения, мы только усложняем будущую поддержку кодовых баз/компиляторов/языка

Вроде бы как строго наоборот всё, и это если работать с возвращаемыми кодами ошибок или всякими GetLastError, errno и прочим, необходимо проверки вставлять собственноручно и после каждой строки

strict aliasing выпиливает лишние обращения к памяти, этого достаточно чтобы дать большой буст (это не считая того что меньше инструкций)

хороший поинт

А ведь это одна из любимых граблей всяких сишников которые думают что float* можно спокойно кастовать в Int*  :)

... но вообще должно быть сильно лучше, Чем сейчас

Это неправильный подход, не надо всё обкладывать в try catch

В том-то и дело, что тут хотя бы какой-то контроль над ситуацией есть, мы можем проверять ошибки ровно там, где они реально могут возникнуть и можем даже требовать проверять возвращаемое значение. В случае с исключениями, абсолютно весь код вокруг становится минным полем и тебе приходится заботиться, а может ли тут возникнуть исключение? А какое? А что делать, если возникло, а вдруг, не известно, какое?

Я где-то видел, как некоторые даже C-библиотеки оборачивали в try/catch, просто не желая разбираться, где можно себе ноги отстрелить, а где нельзя. Наличие непредсказуемости просто вызывает у разработчика апатию и нежелание хоть как-то обрабатывать, потому что это банальное состояние неопределённости, где неизвестно, куда делать следующий шаг, в результате это выливается в снижение качества если не самого кода (уже достижение!), то в снижение качества уведомлений об ошибках точно

Я дал тебе  библиотеку из 20 функций которые возвращают int, и кода который их использует из 40 вызовов этих функций, где именно проверять ошибки и как?

Помимо try/catch нужно ещё всё оборачивать в RAII, это вообще-то тоже вымораживает. А ещё надо каким-то образом убедиться в том, что деструктор не испускает исключений. И при этом не совсем понятно, в чём вообще исключения улучшают жизнь

> мы можем проверять ошибки ровно там, где они реально могут возникнуть

То же самое с исключениями

>  можем даже требовать проверять возвращаемое значение

Нет, это как раз минус кодов возврата, а вот с исключениями такого нет

> приходится заботиться, а может ли тут возникнуть исключение

Об этом вообще не нужно думать если ты не в гугл. Ты не понимаешь просто как надо юзать исключения правильно

Из С библиотек не может вылететь исключение, иначе это гавно библиотека

>"Ты не понимаешь просто как надо юзать исключения правильно"
Именно так

Так а что делать, если хочется хоть какой-то определённости и уверенности в вызываемом коде? А если я не хочу при первом же исключении прерывать ход вычислений, я хочу как можно дольше продолжать обработку, пока это вообще возможно, чтобы показать, например, наиболее подробный лог.

Вообще, я видел TRY(error), сделанный на корутинах, кажется, что с выходом 20 стандарта, это будет первое, что я попробую)

А как насчёт си-библиотек, которые вызывают твои функции по указателям?