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


V>В режиме O1 и O2 в x64 у многих компиляторов не возникает переполнения, т.к. происходит инкремент 64-битного регистра (оптимизация заключается в замене сложения инкрементом, но нет команды инкремента полурегистра), т.е. результат инкремента всё еще продолжает оставаться положительным, поэтому задуманный первоначальный фокус и не срабатывает.
Зачем вы продолжаете писать бред?
1. Команда инкремента "полурегистра", конечно же, есть. Как и инкремент "четверти регистра". Как минимум на Интеле. Что не мешает компиляторам под интел (и при компиляции на интеле) выдавать неверный результат.
2. Понятие "положительности" результата тут нерелевантно. Главное — что и как сравнивать. Даже если мы выполнили инкремент через INC RAX (вместо INC EAX или INC AX), то ничего страшного.
Результат сравнения определяется вариантом инструкции CMP. Мы по-прежнему можем сравнить "полурегистры" или "четвертьрегистры", и весь мусор в старших битах будет проигнорирован.
А отличие знакового и беззнакового сравнения сводится к тому, какие флаги анализируются по его результатам.
3. Для is_max<long> ваши рассуждения неприменимы вообще. У нас в аргумент попадает 0x7FFFFFFFFFFFFFFF, после инкремента получается в 0x8000000000000000, что при знаковом сравнении меньше оригинала. Даже если бы компилятор писали полные идиоты, неспособные отличить int comparison от long comparison.

V>Именно поэтому вторым решением я предложил смотреть прямо в нужный бит, т.к. логику решений Синклер описал — максимальное неотрицательное число это такое, после прибавления единицы к которому вознрикает переполнение. В нужном бите возникает единичка, конечно, просто этот бит не всегда старший в промежуточных вычислениях. ))
Как вы объясните oops в тех случаях, когда этот бит — старший?