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

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

V>>>В данном случае ты даёшь оценку своим фантазиям, бо архитектуры/компиляторы явно определяют своё поведение при переполнении.
S>>Ошибаетесь. Я же привёл пример. Каким образом "явно определённое поведение" приводит к разнице между -O0 и -O2 для приведённого фрагмента?

V>1. Твой пример содержит ошибки, например, для short, т.к. значением short(value)+1 будет значение типа int, т.е. еще до рассуждений об UB необходимо исправить ошибку:
V>

V>template<typename signed_integral>
V>bool is_max(signed_integral value) {
V>    return signed_integral(value + 1) < value;
V>}
V>

Это не отвечает на мой вопрос, т.к. программа выдаёт oops для int. И после вашего исправления она продолжит выдавать oops и для int, и для short.


V>2. Мы наблюдаем невладение предметом
И опять вы приводите нерелевантные примеры, пытаясь усложнить задачу там, где вы и с простым вариантом не разобрались.

V>Но что в любом обсуждении ты теперь на рефлексах считаешь собеседников по-умолчанию идиотами, и даже не мелькает мысли проверить себя — это изрядно утомляет, конечно...
Я не считаю собеседников идиотами. Но иногда бывает так, что собеседник выставляет идиотом сам себя.
Вот что вам помешало перед тем, как фонтанировать заблуждениями, просто пойти по ссылкам на gotbolt, которые приведены ниже в обсуждении?

V>Программа ломается, потому что в ней ошибки. ))
Указанная вами ошибка в ней действительно есть — integral promotions не учитываются. Но ломается она вовсе не поэтому.
Убедиться в этом очень легко, применив предложенный вами фикс:
https://godbolt.org/z/1EGzMnWs5

V>Ты написал некий обощённый код из некоторого обощённого предположения, но это предположение для многих ситуаций ложно.
Вопрос не в том, в каких ситуациях это предположение ложно, а том, почему оно ложно в конкретной рассмотренной ситуации. Но можем и расширить вопрос, посмотрев, как себя будет вести программа для других типов данных.

V>Фишка в том, что для промежуточных вычислений в железе часто используют регистры шириной в слово, т.е. UB возникает прямо в железе — ты можешь проверить это на последних gcc на x64, там будет тот же эффект в рантайм для int, что и в случае short(value)+1, т.е. даже в рантайме программа сломается (без оптимизации), потому что в ней ошибка — ты не можешь гарантировать ширину бит промежуточных вычислений.
Я правильно понимаю, что вы ожидаете неверного поведения от моей программы на "последних gcc на x64 без оптимизаций" потому, что промежуточные вычисления он будет делать в 64 битах?
Это легко проверить — достаточно
а) попробовать починить программу предложенным вами образом
б) попробовать запретить оптимизации в исходной программе
Если вы правы, то а) даст wow, а b) — oops.