LINUX.ORG.RU

История изменений

Исправление next_time, (текущая версия) :

Типа того. Тут вопрос в том, с какими данными мы работаем - если это какая-то абстрактная математическая ерунда, то наиболее лучшим решением проблемы является расширение типа по мере надобности. Но с абстрактной математической ерундой прогер редко имеет дело. Обычно мы имеем дело с какой-то реальной задачей из реального мира. А там ограничения на размер всплывают вполне естественно - например, редко когда пользователь захочет вводить число размером в миллиард - в реальной жизни такое встречается редко, соответственно, поле для ввода должно быть ограничено. В БД тоже хранятся какие-то реальные данные, и, допустим, число сотрудников в организации, равное MAX_INT, скорее всего, является ошибкой. Код ответа сервера вы вообще вряд ли умножать захотите.

Т.е. на деле, вы всё подряд в храните в простом int просто в силу лени, а по факту - вы имеете налицо изъян в системе типов. В плюсах можно наклепать шаблонов для работы с числами ограниченной размерности - и тогда компилер будет корректно проверять переполнение на этапе компиляции. Просто это будет чуть менее удобно, чем работа с простым инт.

Вот я и смотрю из любопытства в сторону других ЯП.

Исходная версия next_time, :

Типа того. Тут вопрос в том, с какими данными мы работаем - если это какая-то абстрактная математическая ерунда, то наиболее лучшим решением проблемы является расширение типа по мере надобности. Но с абстрактной математической ерундой прогер редко имеет дело. Обычно мы имеем дело с какой-то реальной задачей из реального мира. А там ограничения на размер всплывают вполне естественно - например, редко когда пользователь захочет вводить число размером в миллиард - в реальной жизни такое встречается редко, соответственно, поле для ввода должно быть ограничено. В БД тоже хранятся какие-то реальные данные, и, допустим, число сотрудников в организации, равное MAX_INT, скорее всего, является ошибкой. Код ответа сервера вы вообще вряд ли умножать захотите.

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

Вот я и смотрю из любопытства в сторону других ЯП.