Как отловить переполнение границ типа (INT)?

Сразу напишу пример для наглядности:
В 32 битах максимум и минимум int имеет границы: -2147483648 до 2147483647, в показанном примере естественным образом должна была бы быть ошибка(хотя бы уведомление), но его нет... Как отлавливать такие вот не корректные моменты?

И это лишь один момент из интересующих который выведет не верный результат...
Ещё один:
Как бороться?..
Читал что некоторые создают особый тип (эквивалентный например 64 битному), т.к. границы будут дальше, то и результат можно будет сравнить полученное число с текущим, однако всё же границы останутся (теперь на пороге 64 битного числа), и подобный метод не подойдёт, т.к. за границы всё равно может выйти число. Так как в арифметических операциях предотвратить подобное?
П.С. желательно чтоб примеры\инфа была бы применима в динамических переменных, т.е. на этап уже запуска без среды программирования. (собственно из уже получившейся программы)

0

nmcf, насчет менее убогой системы типов - я слышал краем уха, что какие-то Си-компиляторы последнее время позволяют задавать целый тип любой разрядности в байтах. Что могу сказать - давно пора. А насчет "громоздкого умножения и деления" - не более "громоздкое", чем реализация оного для интов на 8-битных платформах - те же последовательные однобайтовые операции. А вспоминая мой недавний нудёж про возможное отсутствие мулов и дивов в списке аппаратных инструкций и тем не менее реализацию компилятором и умножения и деления многобайтовых типов - вышеупоминаемая "громоздкость" не добавляет никакого качественного усложнения концепции.

0

Громоздкость будет в записи этого на ассемблере.

0

Сообщение от nmcf Громоздкость будет в записи этого на ассемблере.

Если смотреть на машинный код, if(res>100500) будет еще более громоздким. Другое дело что оно будет легко переносимым на другую платформу. И не будет геморрою с ручным распределением регистров, которых на x86 чуть больше чем нифига (вроде, на более современных процессорах поправили). Но все равно обидно что не предусмотрели штатных средств контроля арифметического переполнения.

0

Сообщение от Renji все равно обидно что не предусмотрели штатных средств контроля арифметического переполнения.

Как вы это себе вообще представляете?
Вы осознаете какую цену придется заплатить за подобного рода проверки?

Кому нужно - могут склепать какой нибудь класс чисел с проверками и исключениями.

Но в том, что касается фундаментального int,
стандарт языка напротив стремится максимально оптимизировать вычисления.

0

Сообщение от hoggy Как вы это себе вообще представляете?

1) try_arithmetic_overflow секция внутри которой арифметическое переполнение кидает исключение. За пределами секции - переполнение игнорируется.
2) Ключевое слово arithmetic_flags дающее прямой доступ к процессорным флагам содержащим данные о результате последней арифметической операции. Ну да, с оговорками про ухудшение оптимизации и зависимость реализации от платформы.
3) Синтаксическое правило по которому int*int="как удобно процессору" (вообще-то, 32-битовое на 32-битовое внутри x86 дает 64-битовое. Он его по двум 32-битовым регистрам распихивает). Опять же, черт с ними, с оговорками про зависимость от платформы.

Сообщение от hoggy Кому нужно - могут склепать какой нибудь класс чисел с проверками и исключениями.

С неимоверно кривыми потрохами. Потому как у этого класса все равно не будет доступа к аппаратным средствам контроля переполнения.

0

Сообщение от Renji С неимоверно кривыми потрохами. все равно не будет доступа к аппаратным средствам контроля переполнения.

Почему с кривыми? Ну будут вычисления с int производиться в long long. Можно ассемблерные вставки сделать, если очень хочется.

0

Сообщение от Renji 1) try_arithmetic_overflow секция внутри которой арифметическое переполнение кидает исключение. За пределами секции - переполнение игнорируется.

такое решение вроде нормально вписывается.
хотя сама практика - плодить ключевые слова для обработки частных случаев немного напрягает.
поскольку неизбежно влечет за собой разбухание ключевых слов языка.

Грубо говоря, если узаконить try_arithmetic_overflow, то это создаст прецедент,
и захочется узаконить ещё 100500 разных ключевых слов под разные ситуативные моменты.

Сообщение от Renji 3) Синтаксическое правило по которому int*int="как удобно процессору"

В настоящий момент оно итак действует.

В стандарте языка это называется "промоушен типов".
Сложение двух short даст int, например.

4.5 Integral promotions [conv.prom] 1 A prvalue of an integer type other than bool, char16_t, char32_t, or wchar_t whose integer conversion rank (4.13) is less than the rank of int can be converted to a prvalue of type int if int can represent all the values of the source type; otherwise, the source prvalue can be converted to a prvalue of type unsigned int.

Пример:

http://rextester.com/KNZN1500

Сообщение от Renji (вообще-то, 32-битовое на 32-битовое внутри x86 дает 64-битовое. Он его по двум 32-битовым регистрам распихивает)

32 битное на 32 битное может дать 64 битное, только если sizeof(int) есть 64 битное.

Промоушен действуют только на те модификаторы,
чей эффект даёт sizeof меньше, чем sizeof(int).

Это означает, что перемножение двух int всегда даст int независимо от его размера.

А объясняется это тем, что sizeof(int) - это и есть "как удобно процессору"

Добавлено через 2 минуты

Сообщение от Renji С неимоверно кривыми потрохами. Потому как у этого класса все равно не будет доступа к аппаратным средствам контроля переполнения.

такие вещи - это утилитарные классы общего назначения.

им место где нибудь в std/boost.

и их не велосипедят заново под очередную платформу.

для их создания не нужно ничего менять в существующем языке.

мой посыл: сопровождение и потроха таких инструментальных средств - это не проблема его пользователей.
Это проблема - разработчика. А сделать можно. Технически это все вполне себе реализуется.

0

http://www.fefe.de/intof.html
http://netcode.ru/cpp/?click=r.php-393.htm

0

Сообщение от hoggy Это означает, что перемножение двух int всегда даст int независимо от его размера.

Разъясняю на пальцах. Процессор перемножает числа с помощью команды IMUL. Команда IMUL умножает 32-битовый регистр EAX на 32-битовый регистр на выбор программиста. Результат же помещается в два 32-битовых регистра EDX:EAX. Теперь приходит компилятор, говорит "а система то 32 битовая" и выкидывает EDX (старшие 32 бита результата). А надо чтоб не умничал и возвращал все 64 бита.

Сообщение от nmcf Почему с кривыми?

Потому что на ассемблере контроль переполнения реализуется одной командой jo (перейти по метке если произошло переполнение). Все что превышает одну команду jo - криво по определению.

Что касается ассемблерных вставок, они скорее всего всю оптимизацию кода порушат. Грубо говоря, компилятор хотел положить переменную в регистр EAX. Но так как ассемблерная вставка ничего о желаниях компилятора не знает, пришлось класть переменную в память. Иначе как ассемблер до нее доберется?

0

Сообщение от Renji Разъясняю на пальцах. Процессор перемножает числа с помощью команды IMUL. Команда IMUL умножает 32-битовый регистр EAX на 32-битовый регистр на выбор программиста. Результат же помещается в два 32-битовых регистра EDX:EAX. Теперь приходит компилятор, говорит "а система то 32 битовая" и выкидывает EDX (старшие 32 бита результата). А надо чтоб не умничал и возвращал все 64 бита.

Я на самом деле не силен в ассемблере.
Точно не знаю, что там происходит.

Знаю только, что промоушен типов специально для того и существует,
что бы оптимизировать по разрядной сетке машины.

А это означает, что получать 64 бита вместо 32 там, где 32 - это sizeof(int) - не эффективно.

0

мне больше всего понравился вариант:
при условии, что А и В не переполняют инт:

0

Сообщение от Renji Процессор перемножает числа с помощью команды IMUL. Команда IMUL умножает 32-битовый регистр EAX на 32-битовый регистр на выбор программиста. Результат же помещается в два 32-битовых регистра EDX:EAX.

а кроме х86 других архитектур нету?
и каким переходом отлавливать переполнение не разрядной сетки, а диапазона чисел
типа
переполнения разрядной сетки нет, но мы залезли в область отрицательных чисел

0

Сообщение от hoggy А это означает, что получать 64 бита вместо 32 там, где 32 - это sizeof(int) - не эффективно.

Да нет, просто такая поддержка 64 битовой арифметики кастрированная. Умножение, сложение только в 32 битах. Деление позволяет использовать 64-бита как делимое, но результат все равно будет 32-битовым. Для описания всех этих ограничений придется вводить какой ни будь stupid_long_int.

Сообщение от ValeryS а кроме х86 других архитектур нету?

Потому и написал - "int*int=как удобно процессору". Если процессор умеет умножать с повышением разрядности числа - пользуемся этим. Не умеет - ну, что поделать.

Сообщение от ValeryS и каким переходом отлавливать переполнение не разрядной сетки, а диапазона чисел

jo и отлавливать. Флаг переполнения устанавливается при выходе за диапазон знакового числа. А то о чем вы подумали - флаг переноса.

1

Сообщение от Renji Грубо говоря, компилятор хотел положить переменную в регистр EAX

Ну так ты же и предлагаешь jo и прочее для оптимизации, куда ещё оптимизировать, если оформить как функцию?

0

Сообщение от Renji Да нет, просто такая поддержка 64 битовой арифметики кастрированная.

Поддержка 64 битных зависит от процессора.
Если он такое поддерживает, то ничего не мешает перемножать/складывать/делить 64 битные числа.
Если вам это нужно - пожалуйста.

Другое дело, что в 99,(9)% всех случаев, 32 битного типа данных вполне достаточно
для операций над 32битными числами.
И это работает эффективно.

0

Renji, плюсанул вам за некоторый рефреш моей памяти и при этом отсутствие придирок к моим неточностям в этой связи
ЗЫ вся тема напоминает историю проверок выхода за границы массивов и цену которой за это платится. Реализовано во многих языках, делается гораздо проще контроля диапазона целых чисел, и то жрет ресурсы и в Сях летает быстрее потому что всех этих проверок нет. Но при всем при этом, компилятор мог бы быть более юзер-френдли и давать доступ к регистру состояний с джампом по меткам и управляемым поведением при арифметических операциях - специально для тех, кто хочет залезть руками и настроить под себя.

0

Ну, если уж очень хотите знать, то посмотрите класс Integer в JDK. Там есть метод, чтобы уловить переполнение, если я правильно помню.

0

Сообщение от nmcf Ну так ты же и предлагаешь jo и прочее для оптимизации, куда ещё оптимизировать, если оформить как функцию?

Я предлагаю тем или иным образом сказать компилятору "проверяй переполнение". А он уже пускай jo и расставляет. Если делать через функции, нужно как минимум иметь прямой доступ к флагам процессора (он туда хомячит "переполнилось/не переполнилось"). А это опять же будет изменением синтаксиса языка.

Сообщение от hoggy Другое дело, что в 99,(9)% всех случаев, 32 битного типа данных вполне достаточно

Ну да, а потом оказывается что бывают файлы больше четырех гигабайт, жизнь после 2038 года (unix-time) и геймер-Вася скопивший 2 147 483 648 фантиков. Если логика программы допускает арифметическое переполнение, кто ни будь его да устроит.

0

Сообщение от Izual Как отлавливать такие вот не корректные моменты?

Их не надо отлавливать. Их просто не надо допускать.

1

Сообщение от castaway Их не надо отлавливать. Их просто не надо допускать.

Сообщение от Renji геймер-Вася скопивший 2 147 483 648 фантиков

Надо. И желательно чтоб холивар в теме плавно перетёк в точные подсказки по теме, понятные не только тем кто тут 24\7 холиварит))) (было занятно почитать конешно, но всё это на столько глубоко копается, что толку от вашего холивара лишь "моя кобыла быстрее", а мне нужно просто чтоб работало, и желательно "просто")

0