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

@Izual · Регистрация: 13.11.2012

Студворк — интернет-сервис помощи студентам

Сразу напишу пример для наглядности:

C++
1
2
3
4
5
int fx = -2147483648
if(fx == -fx)
{
 //ляляля
}

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

И это лишь один момент из интересующих который выведет не верный результат...
Ещё один:

C++
1
2
3
int fx = 2147483646
int fy = 20;
int fz = fx+fy;

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

@castaway · 23.02.2015, 19:14

А я не пытаюсь холиварить. Я на полном серьёзе. Готов поспорить, что ты не сможешь привести адекватный пример того, когда это нужно.

@Renji · 23.02.2015, 19:33

Сообщение от Izual

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

Точная подсказка - писать свой класс INT с перегрузкой арифметических операций и проверкой их корректности. Ну или вводить принудительные ограничения на диапазон входных значений (Вася не может накопить 2 147 483 648 фантиков, потому что в сокровищницу разрешено положить только 100500).

@hoggy · 23.02.2015, 20:20

Сообщение от Renji

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

в 0,(1)% случаев, когда действительно важно не допустить потенциального переполнения,
вопрос легко решается при помощи тех же лимитов, или использования тех же int64_t

это - к слову о логике. Логика программы зависит только от программиста.
для этого не нужно ничего менять в самом языке.

и не нужно ради редкого юзкейса портить эффективность остальных 99,(9)% всех вычислений.

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

Сообщение от castaway

Готов поспорить, что ты не сможешь привести адекватный пример того, когда это нужно.

я могу привести вам пример,
когда реально на практике использовал лимиты и проверку переполнений:

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

пример:

C++
1
2
3
4
5
6
variant v;
 
v["hello"][10] = true;
v["hello"][11] = 10;
v["hello"][12] = int64_t(10); //<--- хранит 64 битный, хотя циферка 10 влезет и в обычный int8_t
v["hello"][13] = int64_t(20);

Перед отправкой по сети делаем ему:

C++
1
2
v.Minsize(); //<--- все числовые данные пересоздаются в объектах
   // меньшего размера, если это возможно

После этого можно отправить по сети.

При обратном извлечении числовых данных есть два режима:
1. Строгий. Вкладывали int, значит и забирать можно только как int

2. Не строгий. Забрать можно через какой угодно тип,
если его размер способен вместить в себя данные.

При нестрогом режиме циферку 10 можно забрать как int8_t,

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

И пересылать их между серверами.
При этом экономится объем передаваемых данных.

Особенно это актуально для среднего размера баз данных.
Их 64 битные айдишники вполне себе укладываются в какой нибудь 16 битный тип.

@castaway · 23.02.2015, 20:28

Сообщение от Izual

И желательно чтоб холивар в теме плавно перетёк в точные подсказки по теме

Сообщение от Izual

Как отлавливать такие вот не корректные моменты?

Если по теме, то язык С++ не даёт таких возможностей. А не даёт он их потому, что они в нём не нужны. Если хочешь отловить переполнение - пиши на ассемблере, какого ты вообще полез в С++ ...

@Renji · 23.02.2015, 20:39

Сообщение от castaway

Если по теме, то язык С++ не даёт таких возможностей. А не даёт он их потому, что они в нём не нужны.

Наступил коммунизм. Каждому дали по потребностям. В магазине висит плакат "сегодня в мясе потребности нет".

Вот чем-то мне все эти "в C++ нет (подставить возможность)? Значит, не нужна" тот анекдот про коммунизм напоминают.

@castaway · 23.02.2015, 20:57

Renji, мне твои суждения не очень понятны, говори "прямо".

hoggy, привет, давай "на ты". Мне интересен твой вариант как задача, и над ним стоит подумать, по этому сходу ответ не дам. На счёт ТС я уверен, что он не смог бы предоставить и такой вариант. Но это не значит, что его нельзя решить по-другому. Давай подумаем.

@_Ivana · 23.02.2015, 21:00

Да не хочет ТС ассемблер. И думать не хочет. А хочет "чтобы попроще" за него все компилятор понаписал, и 100500 проверок в рантайме, чтобы на 0 делилось без еррора, за границы массива не залазилось, диапазоны типов не превышало... И чтобы еще само при этом знало как и когда надо сделать. Язык для обезьяны он хочет.

@castaway · 23.02.2015, 21:03

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

@Renji · 23.02.2015, 21:14

Сообщение от castaway

Renji, мне твои суждения не очень понятны, говори "прямо".

Прямо: нет никаких гарантий что в программу не вкралась ошибка вызывающая арифметическое переполнение. Раз ошибка может случиться, значит есть потребность ее отслеживать. А не отвечать "сегодня в ловле переполнения потребности нет".

@hoggy · 23.02.2015, 21:16

Сообщение от castaway

но где там нужна проверка на переполнение?

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
int64_t src = 10;
 
variant v = value; //содержит int64_t
 
v.minsize(); //выполнил проверку лимита, 
//и пришел к выводу, что для хранения достаточно int8_t
 
 
.....
 
char re1 = v; //<--- забираем данные
//если извлекаемое значение не влезает в приемник,
//то вылетает исключение

@_Ivana · 23.02.2015, 21:21

hoggy, делается за пару тактов предварительным чтением в широкий тип и накладыванием И с маской на якобы несуществующие биты, хоть по 5 или 7 бит принимай - никакие типы на границы проверять не надо, арифметики нет.

@Izual · 23.02.2015, 21:21 **[ТС]**

Сообщение от castaway

А я не пытаюсь холиварить.

В общем то это не вам... 2 страницы ответов, которые уходят слишком далеко в тему(или уже нет), где начинаются вот такие вот ответы типа:

Сообщение от castaway

А не даёт он их потому, что они в нём не нужны

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

Сообщение от Renji

В магазине висит плакат "сегодня в мясе потребности нет".

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

Теперь по теме.

Я думаю что такой пример будет более ярко выражать мою мысль:

C++
1
2
int a=85300000, b=30, c=0;
c = a*b

С виду вроде можно предположить, что операция опасна переполнением, т.к. кол-во исходных разрядов чисел 2+8(10знаков, лимит в int32 - 10). Понятно, что если кол-во разрядов чисел не превышает потенциально 5, то смысла проверять нету, но вдруг фантиков стало реально много.
Использовать int64 - значит считать числа в 64битном формате, а потом переводить в 32 с условием на лимит, только вот это уже 3 или 4 операции как минимум, в место одной, а это по моему накладно. Я пока что склоняюсь к варианту использования блоков try/catch/throw, но пока что ни одной мысли к данному способу не было озвучено и продемонстрировано.

@hoggy · 23.02.2015, 21:29

Сообщение от _Ivana

hoggy, делается за пару тактов предварительным чтением в широкий тип и накладыванием И с маской на якобы несуществующие биты, хоть по 5 или 7 бит принимай - никакие типы на границы проверять не надо, арифметики нет.

Какой то сферический конь в вакууме.

@castaway · 23.02.2015, 21:30

Сообщение от Renji

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

Есть такая гарантия, и эта гарантия - "качественный" программист, который пишет программу. Если в программе есть такая ошибка, значит программист не достоен называться программистом.
Поэтому повторяю еще раз: в языке C++ нет таких механизмов именно потому, что они там не нужны.

hoggy, похоже, что мы говорим о разных "переполнениях".

@hoggy · 23.02.2015, 21:31

Сообщение от Izual

Я пока что склоняюсь к варианту использования блоков try/catch/throw, но пока что ни одной мысли к данному способу не было озвучено и продемонстрировано.

и не будет.

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

@Izual · 23.02.2015, 21:33 **[ТС]**

_Ivana, вася, холи вар устраиваеш. Так ещё и не правильно интерпритируеш мои мысли, в корне не правильно. Я не против ни первого, ни последнего, но выход за пределы языка, который используется должен быть оправдан, тут же ни кто ещё не предложил других вариантов.(вижу только асм и сравнение с 0 и начальным числом)
Этого мало, т.к. я в асм нуб, то для меня потенциальное использование асма является экстремумом, который желательно избежать. Почему - потому что если я что то не правильно напишу - последствия могут быть не предвиденными, насколько - даже представить трудно в виду не знания асма. Я не думаю что нет иных способов, предусмотренных стандартами языка или стандартными библиотеками которые могли бы помочь в решении. А тратить время(год, 2?) на изучение асма - не практично.

@hoggy · 23.02.2015, 21:34

Сообщение от castaway

похоже, что мы говорим о разных "переполнениях".

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

@Izual · 23.02.2015, 21:37 **[ТС]**

Сообщение от hoggy

склоняетесь к тому, чего не существует в природе

Разве конструкция try/catch/throw которая при использовании stl не создана ли для борьбы с exceptions?.. Чем и должно является арифметическое переполнение типа.

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

Сообщение от Renji

вводить принудительные ограничения на диапазон входных значений

Так если первые два числа были в рамках, а третье в результате арифметической операции не влазиет - то вопрос то так и остался - как отследить это?..

@castaway · 23.02.2015, 21:40

Сообщение от Izual

т.к. из за таких нелепых комментов начинается бардак

На самом деле, бардак начинается из-за таких нелепых вопросов.

Сообщение от Izual

Я думаю что такой пример будет более ярко выражать мою мысль

Мысль он выражает, но в реальности такое никто не делает. По этому и необходимости в этом тоже нет.

@hoggy · 23.02.2015, 21:41

Сообщение от Izual

Чем и должно является арифметическое переполнение типа.

долговая расписка имеется?
если нет - стало быть ничего оно вам не должно.

вы похоже не осознаете последствий своих фантазий.

механизм исключений использует медленно-медленную RTTI.
то, что вы себе помыслили - не просто не эффективно, это - черезвычайно медленно.
Более тормозного варианта себе придумать сложно.

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

Новые блоги и статьи Все статьи Все блоги /
Алиса нашла кучу ошибок компиляции и запуска в проекте, который без проблем компилировался и запускался))) anaschu 30.06.2026 Я пока посмеюся, но завтра проверю. А вообще интерсно. Дал алисе файл, в котором точно нет ошибок компиляции и запуска, и попросил их найти. Нашла кучу))) Критические ошибки, мешающие компиляции и. . .	сукцессия 16. Общий обзор, в основном что бы другие ии поняли anaschu 29.06.2026 # Передаточный документ: модель микоризной сукцессии (для нового чата) Этот документ предназначен для того, чтобы новый чат Claude мог продолжить работу без необходимости заново разбираться в. . .	сукцессия 15 неявная схема anaschu 29.06.2026 Алиса Калибровка параметров симбиотической модели: технический обзор Содержание: Введение Постановка проблемы Технические аспекты реализации Процесс внедрения изменений	сукцессия 14. Обновленная схема модели anaschu 28.06.2026 ГЛОБАЛЬНАЯ ОПИСАТЕЛЬНАЯ СПЕЦИФИКАЦИЯ ЭКОСИСТЕМНОЙ МОДЕЛИ «SOIL CHEMISTRY & MYCORRHIZA 2. 0» https:/ / ibb. co/ NnkGpfMd Представленная интегрированная схема описывает непрерывную нелинейную. . .
сукцессия 13. Питон модель трехзонного мицелия, пока что в основном арбускулярного anaschu 28.06.2026 ## Разработка агентной модели микоризной сукцессии: от выявления артефактов к созданию комплексной системы ### Аннотация Представлено исследование по разработке агентной модели микоризной. . .	сукцессия 12. краткий список проверок модели перед запуском. anaschu 27.06.2026 Скрытые отказы в моделях систем динамики (SD-models) экологических систем: два случая из практики Контекст Разбирался прототип модели систем динамики (SD-модели) микоризной сукцессии: пять. . .	Сукцессия 11. Проверка орудий перед войной: разработка через тестирование anaschu 27.06.2026 Как не дать модели соврать самой себе: проверки для симуляции микоризной сукцессии Введение Когда вы строите математическую модель живой системы — грибов, растений, почвы — главная опасность. . .	10 сукцессия. Питон код войны грибов и растений anaschu 27.06.2026 import numpy as np class PlantAgent: def __init__(self, name, strategy, initial_biomass): self. name = name self. strategy = strategy # "greedy" (широколиственные) или. . .

@castaway 4986 / 3093 / 456 Регистрация: 10.11.2010 Сообщений: 11,170 Записей в блоге: 10
	23.02.2015, 19:14
	А я не пытаюсь холиварить. Я на полном серьёзе. Готов поспорить, что ты не сможешь привести адекватный пример того, когда это нужно. 0

@castaway 4986 / 3093 / 456 Регистрация: 10.11.2010 Сообщений: 11,170 Записей в блоге: 10
	23.02.2015, 20:57
	Renji, мне твои суждения не очень понятны, говори "прямо". hoggy, привет, давай "на ты". Мне интересен твой вариант как задача, и над ним стоит подумать, по этому сходу ответ не дам. На счёт ТС я уверен, что он не смог бы предоставить и такой вариант. Но это не значит, что его нельзя решить по-другому. Давай подумаем. 0

@_Ivana 4949 / 2289 / 287 Регистрация: 01.03.2013 Сообщений: 5,991 Записей в блоге: 32
	23.02.2015, 21:00
	Да не хочет ТС ассемблер. И думать не хочет. А хочет "чтобы попроще" за него все компилятор понаписал, и 100500 проверок в рантайме, чтобы на 0 делилось без еррора, за границы массива не залазилось, диапазоны типов не превышало... И чтобы еще само при этом знало как и когда надо сделать. Язык для обезьяны он хочет. 1

@castaway 4986 / 3093 / 456 Регистрация: 10.11.2010 Сообщений: 11,170 Записей в блоге: 10
	23.02.2015, 21:03
	hoggy, несколько раз прочитал твой пост.. может быть я неправильно интерпретирую какие-то термины, или просто не понимаю суть примера, но где там нужна проверка на переполнение? 0

@_Ivana 4949 / 2289 / 287 Регистрация: 01.03.2013 Сообщений: 5,991 Записей в блоге: 32
	23.02.2015, 21:21
	hoggy, делается за пару тактов предварительным чтением в широкий тип и накладыванием И с маской на якобы несуществующие биты, хоть по 5 или 7 бит принимай - никакие типы на границы проверять не надо, арифметики нет. 0

@Izual 143 / 122 / 21 Регистрация: 13.11.2012 Сообщений: 1,564
	23.02.2015, 21:33 [ТС]
	_Ivana, вася, холи вар устраиваеш. Так ещё и не правильно интерпритируеш мои мысли, в корне не правильно. Я не против ни первого, ни последнего, но выход за пределы языка, который используется должен быть оправдан, тут же ни кто ещё не предложил других вариантов.(вижу только асм и сравнение с 0 и начальным числом) Этого мало, т.к. я в асм нуб, то для меня потенциальное использование асма является экстремумом, который желательно избежать. Почему - потому что если я что то не правильно напишу - последствия могут быть не предвиденными, насколько - даже представить трудно в виду не знания асма. Я не думаю что нет иных способов, предусмотренных стандартами языка или стандартными библиотеками которые могли бы помочь в решении. А тратить время(год, 2?) на изучение асма - не практично. 0