Alexey Veselovsky писал(а):
Это просто не правда. Вы не знаете С++. int, long и так далее в С++ не имеют фиксированой длины. На разных платформах, разных компиляторах она будет разная. Где-то int будет 8 бит, где-то 16, где-то 32, а где-то 64.
.
Честно говоря, не ожидал столь бурной реакции на высказанное мнение, да еще с переходом от обсуждения концепции языка к обсуждению моих навыков.
Ну да ладно.
За все платформы говорить не стану. Сошлюсь на это:
http://msdn.microsoft.com/en-us/library/296az74e.aspxINT_MAXMaximum value for a variable of type int. 2147483647
Насчет обвинения в незнании С++ - оправдываться не буду. Сразу признаюсь. Не гуру. Никогда не любил С /С++ и програмирую на них по необходимости.
предпочитаю Blackbox. Так что, коллеги, не стоит отвлекаться на обсуждение моей персоны. Она того не заслуживает )))
Alexey Veselovsky писал(а):
Ваша же проблема в том, что вы элементарно неправильно написали приложение. Вместо того, чтобы сделать typedef uint32_t integral_int_t, и в последствии именно им (integral_int_t - да, задача по формированию integral image мне знакома) пользоваться везде для обработки изображений, вы напрямую везде использовали сырой тип int, который не дает каких-либо гарантий по ёмкости. Соответственно вы лишились возможности при изменении условий (большие изображения) одной строчкой гарантированно изменить ёмкость целочисленного типа в нужных местах.
Насчет "чтобы сделать typedef uint32_t integral_int_t," - увы, мои предшественники. с чьими кодоми я сейчас разбираюсь, предусмотреть все что могло случиться через несколько лет вряд ли могли. Работали с тем, что есть.
Насчет "сырого типа int". На мой взгляд типы INTEGER и REAL в языки программирования были введены задолго до появления Оберона,начиная с Фортрана и Алгола и присутствуют практически во всех компилируемых языках. И в большинстве расчетных задач главное для INTEGER - диапазон, а для REAL - диапазон и количество знаков в мантиссе. И чем они больше, тем меньше вероятность переполнения и ошибок округления. И если алгорит работал без переполненийи и приемлемымыи ошибками округления на 16 битной платформе, то уж тем более он работал на 32х битной.
С этой точки зрения уж коли INTEGER и REAL в процессе развития эволюционировали с 8 битных до 32 битных, то зачем же пресекать этот процесс зафиксировав INTEGER на 32 бит? Пусть и дальше расширяются до 64х, 128 и т.д. Не вижу в этом ничего плохого.
Ну а для типов с фиксированной разрядностью ,(IMHO) лучше было бы иметь названия, которые однозначно определяют их реализацию: BIT, BYTE, WORD, INT16, IN32 и т.д.