Здравствуйте, vdimas, Вы писали:
V>Порвало оно наивную реализацию, а так-то отсосала от ненаивной.
А что вы имеете в виду под "ненаивной"?
V>Но не в этом дело, мне там на скорости было малость до фени, я среагировал на некорректность генерируемого кода — он генерит корректный код только для узкого класса сценариев, никак не диагностируя, что порет лажу в остальных случаях.
И в каких же случаях он "порет лажу"?

V>Очковтирательство заключалось в этом и оно непосредственно связано с топиком, иначе бы я не упомянул тот случай.
V>Это просто у вашей братии вот такой сволочной подход — молча раскладывать лепешки по коду, хлопая честными глазками.


V>Я тебе довольно быстро указал на проблему (от первого же поста, в котором взял за труд верифицировать твоё решение), но ты или долго не мог понять её суть, или пытался играть на публику в расчёте на то, что читатели не станут вникать.
В реальности вы там начали нести пургу, за которую были высечены несколькими участниками.

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

V>Я не вижу простого рабочего подхода при решении тобой технических задач.
V>Беспокойная твоя головушка создаёт слишком много лишнего информационного шума, который никому нахрен не нужен.


V>Перехвалили в детстве? ))
Скорее вас недохвалили. Отсюда постоянные попытки, обосрамшись, сделать вид, что "ничего не было", на крайняк "меня не так поняли".

V>Ошибка была в самом байт-коде.
Несомненно была.

V>Ожидаемым поведением ошибки ядерного уровня, ес-но.

V>Было сказано, что BSOD — это штатное ср-во реакции, и что в иных случаях до него даже не доходит.


V>Чтобы "отформатировать диск"? (С)
Для того, чтобы угрозы проверять. Напомню, речь идёт о софте, выявляющем трояны.
Основное преимущество управляемого кода — как раз возможность изолировать ошибки.

V>Причём, учитывая, что речь о ср-ве обеспечения безопасности, лично я не уверен, что стоит позволять пользователю продолжать работать в скомпрометированной на ядерном уровне среде — вдруг кривой байт-код является способом атаки?


V>А так уже высмеял твою толерантность к байт-коду — ты снова запросто рассуждаешь о том, что байт-код может быть кривой.
По-хорошему, байт-код нужно верифицировать, но кто ж знает, что у них там за байт-код. Это ж какая-то самодеятельность.

V>(Но ни боже упаси будет кривым нейтивный код — тебя порвёт на сотни постов гневно-праведного обличительства, чемпион ты наш по лицемерию)
"Сотни постов". Ага. Стоило один раз упомянуть, как у vdimas порвался пукан, и нас накрыло коричневой волной.

V>Ты опять заврался.
V>Я же тебе продемонстрировал в чём дело — сохранил результат в промежуточную стековую volatile-переменную (семантика volatile в плюсах иная, чем в дотнете).

V>И я продемонстрировал тебе суть происходящего и на C#, чем подорвал твой анус, помнится.


V>Я думаю, что ты упирался лишь по той причине, что до моего появления в подветке успел наговорить тонны первокласнейшей ереси.
Ну, то есть вы так до сих пор и не поняли, что никакой ереси я там не нёс, зато вот над вашими постами смеются примерно все, кто понимает устройство компилятора?

V>И чего там понимать-то в том UB? — прямо по стандарту разрешён промоушен до более широких типов в промежуточных значениях вычислений.
Ну вот, вы продолжаете позориться. Понятно, почему не хотите в форуме название работодателя светить — вдруг коллеги вас поиском случайно найдут, ржать будут годами.
За истекшее время можно было сходить и найти соответствующий пункт стандарта. Заодно понять, почему он неприменим к рассматриваемому примеру.

V>Это всё способы, во-первых, улучшить точность вычислений, а во-вторых — не натыкаться лишний раз на UB в случае переполнений.

V>Более того — я показывал тебе ассемлерные распечатки разных компиляторов, где было видно, что те позволяют себе иногда расширять int32 до int64 унутре в регистрах.
Во-первых, типизация промежуточных значений происходит задолго до того, как появятся какие-то регистры. Так что продемонстрированные вами расширения — это уже фаза кодогенерации, на этом этапе компилятор все семантические оптимизации давно применил.
Во-вторых, осталось показать, как это работает для суммы двух int256. Куда она там будет расширяться, и почему компилятор позволяет себе выбрасывать код для этого случая безо всякой оглядки на регистры.

V>И да, повторю свою мысль — когда-то это всё дойдёт и до дотнета, несмотря на твой визг "низачто и никогда!"

V>Разумеется, дотнет еще будет развиваться в деле оптимизации, а значит, список его UB будет расширяться примерно так же, как постепенно расширялся список UB в плюсах.

Впечатляющий пример глобального непонимания.
1. Не понимаете, что именно делает компилятор, и как он это делает, для конкретного случая.
2. Не понимаете, как выводятся типы промежуточных результатов в арифметике C++. В частности, путаете integral promotions с signed overflow.
3. Не понимаете причин, по которым компиляторы С++ делают именно так. Заодно не понимаете последствий. В частности, отсюда ваши наивные заблуждения вида "ну вот я давно пишу такое на MSVC, и там всё хорошо".
4. Не понимаете закономерностей развития индустрии, отсюда ваши прогнозы про внедрение UB в дотнете.