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

V>Да ложь это.
Нет, это вы не понимаете.
V>Проверка индекса при доступе к массивам — это фича конкретного объекта, а не среды исполнения.
Смотря как реализован доступ к массивам. Например, в дотнете это специальная инструкция байт-кода, за проверку в ней отвечает среда исполнения.
Не получится руками сделать такой же "объект" и не сделать проверку.
V>Запросто в опкодах получай ссылку на данные и лезь по произвольному индексу, гадя в произвольную память, бгг...
Это зависит от конкретной среды исполнения. Можно убрать unmanaged pointers, и возможность "лезть по произвольному индексу" исчезнет.

V>Проверка на null перед вызовом метода объекта?
V>Это и вовсе фича компилятора конкретного языка, который подставляет callvirt вместо call.
Вы почему-то думаете, что дотнетом исчерпывается мир виртуальных машин. Нет, это не так. Дотнет — компромиссная технология, в нём пришлось принять ряд спорных решений.
Это не означает, что сама по себе идея управляемых сред неверна.

V>Но VM тут не при чём, такие же есть и нейтивные технологии, которые тоже разменивают производительность на подстраховку.
Да без проблем. Давайте, расскажите мне про эти нейтивные технологии. А лучше — не мне, а разработчикам CrowdStrike. А, и ещё авторам видеокодеков, а то Adobe Premiere до сих пор нет-нет, да и упадёт при редактировании видео. Где-то в недрах кодека у него NRE происходит.

V>Потому что не оттуда и не туда копали, я тебе когда-то объяснял — копать надо было в сторону зависимых типов.
V>Безопасность будущих программ кроется именно там, а не в байт-коде или нейтивном.
V>Это вообще условности. ))
Да, всё верно.

V>Плюс ранее в подветке рассуждал о необходимости некоего особого режима для подгружаемого для исполнения кода.
Чего?

V>Да кароч, в 2024-м с этим глобальным враньём можно было бы уже и закончить. ))
Ну так заканчивайте.

V>Ты ведь не вникал, как компиляторы обслуживают потенциальные UB?
Конечно же вникал. У нас тут как раз курс лекций читался на эту тему — я походил, послушал

V>Нифига себе ожидания...
V>Пипец махровое нубство. ))
Учитесь, коллега, никогда не поздно разобраться, как это работает.

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

V>Ну ты реально тогда считаешь компилятор "черным ящиком", и на этом основании мысленно приписываешь ему любые магические св-ва. ))
Нет, я как раз случайно знаю, как работает компилятор

V>И о каком "понимании устройства" ты сейчас говоришь?
V>На уровне Ахо+Ульмана? Вирта? Хантера?


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


V>Код открыт, иди изучай.
Отметим, что ссылки на стандарт по-прежнему нет. Ну, можете ссылку на код с if-else мне показать.

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

S>>За истекшее время можно было сходить и найти соответствующий пункт стандарта. Заодно понять, почему он неприменим к рассматриваемому примеру.

V>Ты про плавучку? ))
Нет, я про int256.

V>Т.е. ты не знал, что есть фаза оптимизации при конечной кодогенерации?
Естественно знал.
V>И что эта фаза чуть ли не основная по эффективности сегодня?
Нет, она там в последнюю очередь
V>Семантические, это, надо понимать, альфа, бета и эта-преобразования? ))
Я же вам говорил — разработчики компиляторов этими терминами не пользуются. Вы опять выдаёте себя с головой — нет у вас никакого опыта в "парсинге, синтаксическом и лексическом анализе, кодогенерации и оптимизации". В лучшем случае в ВУЗе 30 лет тому назад курсовик делали с разбором Паскаля.


V>__int256 пока что не стандартный тип, тикетов и багов в компиляторах, его поддерживающих, пока хватает.
Ну, пусть будет int128
V>Вот когда все компиляторы подтянутся, тогда этот тип войдёт в стандарт, а пока что это попытка убежать. ))
Не убежите вы никуда. Компилятор все типы обрабатывает одинаково — потыкайте палочкой да убедитесь. Особенности возникают только с типами short и signed char — потому, что для них в стандарте оговорены integral promotions. Никогда компилятор ничего не расширяет шире инта — стандарт ему это запрещает. И сохранение в память тоже не имеет никакого отношения — если так получилось, что на целевом процессоре нет int32 операции, то кодогенератор, естественно, сгенерирует код для int64. Но потом он обрежет результат — даже если этот результат промежуточный, и в память напрямую он никогда не попадёт.

И эзотерика тут ни при чём — обычная инженерная логика.

V>Предположу, что пока что "тупо" использовали ту же ветку, что для других целых.
Ваши предположения были бы хороши, если бы вы их подавали с меньшим апломбом и большей скромностью.
Нет, так не работает. Если бы компилятор произвольно расширял сложение, скажем, int64 до __int128, то тогда у нас бы (a+b)/2 работало корректно. Но ведь нет — вы не найдёте компилятора, который бы вам расширил аргументы, сложил, поделил, и потом сузил. Как вы думаете, почему? И зачем он, по-вашему, делает это для случая int64+1?

V>А ты подтвердить свои рассуждения ничем не можешь, заметь, только позицией "А баба Яга против!"
Могу подтвердить ссылкой на стандарт. Но сейчас — ваша очередь.

V>Но озвучить эти причины, показав хотя бы схематически рассуждения компилятора, ты не в состоянии, верно? ))
Я схематически их уже озвучивал.