> К каждому числовому типу прикручены куча типажей которые определяют поведение данных при
> возникновение этих ситуаций. Другое дело что логической ошибки это не исправляет.Проц ничего про это не знает. Поэтому вы либо лепите кучу софтварных проверок и код получается тормозным УГ либо если терять столько в скорости и пухлости кода не катило (зачем вам дотнет очередной?) - ну значит этих проверок и не будет. Для очевидных случаев что-то как-то можно компил тайм, но попробуй проверить в компилтайм вон то, считаемое из юзерского ввода или внешнмх данных, ага? Это нерешаемая задача, внезапно.
> Если Вы не заложились на максимальный результат и помещаете, например, результат
> умножения двух операндов в ячейку того же размера то это Ваша
> тупость, а не вина компилятора.
В общем случае да. Хотя вот тут даже чуть лучше...
1) Компилер в принципе даже наверное мог бы теоретически прочухать этот момент и варнинг кинуть, если не может вот тут строго доказать что входы этого всегда достаточно маленькие. Особенно если прогер не накастовал явно, изъявив желание знать лучше чего он хочет.
2) Вот на именно эти случаи у процов даже некая поддержка железом может и быть.
А вот с каким-нибудь более приземленными операциями, типа
uint8_t a, b, c;
a = 10;
b = 20;
c = a - b; // <- нет, возможно, мы и правда хотели миенно это. Но - не факт.
Это обоюдоостро. Крипто и проч это использует для быстрых битовых операций, операций по модулю и проч. Если оно всегда будет валиться как невалидное - вам крайне не понравится изменение скорости работы крипто, кодеков, сжатия и прочих тяжелых алго где это как раз важно.
В вот именно этом случае компилер даже заранее знает ответ. И может варнинг кинуть. Де факто оптимизер оформит вон то как одну команду типа mov Rx, #const посчитав const в компилтайме еще. Но для пользовательского ввода например вы это сделать не сможете.
> Но верифицировать корректность значения Раст позволяет в этом случае.
По большому счету он не так уж далеко от сишки в работе с целыми ушел, просто менее дурно сделал некоторые вещи которые в си зачем-то очень криво специфицированы были "а потом все привыкли".
> Результат не выйдет за пределы и будет признак переполнения, например.
Вариантов мало: либо это будет софтварный код с кучей проверок - и соответственно жирным медленным кодом который в алгоритмике будет полный швах, либо это будет без лишних проверок но никакие флаги не поймает.
И проблема весьма фундаментальная: да, проц ставит флаг. Но его отлов - это дополнительные командочки, не нужные для самого вычисления, якорящие скорость и размер кода в разы. И если у вас какое-то крипто вместо 300 мегов в секунду сделает 100, на одном и том же алго, удвчи убедить всех что они должны именено вашим кодом пользоваться во имя луны. И докупить втрое больше серваков, за свои. Или камни втрое мощнее. Угу, за свои. Щас.
Ну а нормальный вариант - заказать процу 1 раз на батч вычислений эксепшн при вон той ситуации и считать без лишних командочек, но если ситуация возникла и проц знает что ее обработку заказали, то вот хардварный эксепшн, обработчик, эскалация этого в ос и юзеровский код... и вот там оно уже может предметно думать что оно хочет по этому поводу делать, когда проц отсигналил. В смысле, при этом можно сочетать гибкую реакцию софта с скоростью железа без разбавки лишними командами. А без этого - оно уже не то. И раст не может решить эту проблему, у него проверки int в рантайм только в дебаг билдах, вот как раз поэтому. Но дебаг билды гоняют во, а релизы во. И кой-кто еще откушает за свои рассказы о секурности...
