Здравствуйте, Sinclair, Вы писали:

CC>>Проблема в твоих руках
S>Да, действительно, потерял при копи-пейсте.


CC>>А где тебе написали конкретно что "UB — ерунда"?
S>Ну, например, поставили фейспалм на простое утверждение "UB, из которого язык состоит чуть менее, чем полностью".
И сейчас поставлю, потому что категоричность сего утверждения фейспалмова чуть более чем полностью
Теперь твоя очередь объяснять как ты из моего фейспалма вытащил утверждение "UB — ерунда"

S>Вот я вижу, что интовая арифметика используется примерно в каждой первой программе.
Что именно ты тут понимаешь под "интовая арифметика"?

S>Что вы называете "странными конструкциями"?
метапрограммирование

S>Compile-time вычисления сами по себе штука хорошая, поскольку позволяют сильно улучшить перформанс программ без потери общности. Те самые zero-cost abstractions, ради которых люди и выбирают C++ вместо менее упоротых языков.
Вот только не надо забывать что compile-time вычисления работают НЕ по правилам платформы, под которую выполняется компиляция.
То, что ты в данном примере называешь UB — на самом деле очень даже defined behavior. Неожиданный — да, но не undefined.

S>

S>long avg(long a, long b, long c)
S>{
S>  return (a+b+c)/3; 
S>}
S>

А что именно ты тут считаешь UB? Переполнение знакового типа имеет очень даже defined поведение для платформы, и если погромист не знает что творит — это недостаток квалификации.

S>Когда вы писали "у меня точно такой же код", я сходу заподозрил, что у вас там беззнаковая арифметика.
А у меня абсолютно везде беззнаковая, кроме тех редких мест где знак именно что нужен.

S>Как раз у вас в предыдущей попытке compile-time вычисления прошли "честно", и получили правильный результат.
Потому что "оптимизатор" по какой то внутренней причине ниасилил свернуть формулу в символьном виде, сработал fallback path и он формулу посчитал внутри себя на таких же типах, на том же железе.