Имеем код
Компилятор будет трактовать операнды 320 и 240 как имеющие тип int? Результат будет зависеть от разрядности int(16/32), правильно я понимаю?
И вообще, когда говорят "16ти битный компилятор" имеют ввиду именно разрядность int?
На C2000 int 16ти битный и a получается == 11264, хотя на самом деле должно быть 76800.
А что,если так?чё получим?

или так

ну так то понятно, что всё будет OK

Сбивает ещё то, что в какой-то книге довелось прочитать, что тип будет взят от первого операнда... потом на форуме видел, что такие вещи компилятор трактует как имеющие стандартный тип(есть вообще такое понятие?).

Копнуть ISO/IEC 9899:1999 пытался, но без привычки это достаточно сложно....

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

Как uint32_t.
А вот что такое uint32_t - надо смотреть где это тип определяется.

Интуитивно можно догадаться, что это некий UNSIGNED тип.

Ну очевидно, что все эти варианты будут работать правильно. Кстати тулз 5.2.1 для первого примера( 320 * 240 ) выдаёт warning: "integer operation result is out of range". Значит он их определяет как int. В данном случае можно писать красивее:

Как там в стандарте сам не знаю .

ps: uint32_t тут должен определяться как unsigned long.

Да, int - платформеннозависимый тип. Для определенности вы можете, например, написать:


Но я бы сделал так:

а я бы просто

uint32_t a = 320L * 240L;

На самом деле смысл там такой - если все операнды помещаются в int, то операция и производится как int (а если калибр операндов меньше, чем int, они к нему приводятся, это называется integer promotion) . Калибр int'а, естественно, зависит от платформы.

Соответственно, оба операнда (320 и 240) в int помещаются и операция производится в калибре int, только вот результат произведения не лезет. Достаточно указать, что один из операндов 32хбитный и все будет хорошо.

Ну uint32_t я намеренно использовал для того, чтобы однозначно определить, что это именно unsigned 32бита.

uint32_t a = 320L * 240L;

Ну так а на другом компиляторе, где long будет 64бит - будет уже оверхед?

Ну с const'ами то ясно, что самый правильный вариант.

Ну а вообще, как оно в стандарте то?
А почему достаточно первый определить как ul и всё работает? А если операнда три? А если не левый, а крайний правый сделать ul
ну типа uint32_t a = 320 * 240 * 2ul;

Как вообще по стандарту? Что сказано о таких случаях?

в компиляторов для настольных ПК 64 бита - это long long))

а long = int = 32 бита...


uint32_t a = 320 * 240;

компилятор будет рассматривать обе константы как типа int. если int 16 бит - будет переполнение...

если операндов несколько... компилятор определяет самый "длинный" или "сложный" тип среди операндов и все приводит к нему. После выполнения операции он начинает думать, как его привести к переменной, которой ему нужно присвоить результат.

Не будет оверхеда, так как результат все равно обкоцают до uint32, и оптимизатор, понимая это, воткнет константу наиболее оптимального для платформы типа.

oops, чё-то я малёк запутался уже

Вооот. Вот это то, что хотелось знать. СПАСИБО!

А ещё вопросик: если в выражении есть скобки это что-то меняет? Я имею ввиду выбирать самый длинный и сложный он будет не смотря на скобки? А то был у меня один странный случай, я там вроде указал самого жирного, а чё-т не работало, пока всёх явно к 32бит типу не привёл.... Щас уже не вспомню толком где это было... Показал бы конкретное выражение. Там были скобки, точно помню. Ещё тогда подумал, что что-то я не понял в этой жизни

Неправильно.

В указанном порядке (например, для операции умножения - сдева направо) вычисляются выражения над двумя операндами.
И, соответственно, promotion выполняется для первой пары операндов. К вычислению второго умножения приходит в качестве левого операнда то, что получилось в результате умножения (с наиболее "старшим" типом из операндов), затем делается "продвижение" среди пары ыторых.
То есть, в выражении

2 * 3L * 4.0

сперва 2 делается long, потом умножается на 3, затем результат делается float и умножается на 4.

Скобки, естественно, меняют порядок вычислений.

гмммммм... ну ваще-то да... как-то оно так.

Этот тип определен в stdint.h, означает 32-битовое беззнаковое целое и вместе со всем содержимым stdint.h описан в стандарте C99.

Еще раз уточним. Операции бывают унарные (один операнд, x = ~y), бинарные (два операнда, x = y * z) и тернарные (такая только одна: x = y ? z : i). Все выражение разбивается на эти примитивы в соответствии с приоритетом операций. Естественно, скобки влияют на приоритет. Т.е. выражение a = b * c * d - это на самом деле три выражения:
tmp1 = b * c;
tmp2 = tmp1 * d;
operator = (a, tmp2);
И для каждого из них отдельно применяются правила неявных приведений типов.

Так будет корректней:
Без статика возможны "игры разума" компиляторов...
И ещё, никакого оверхеда быть не может, т.к. константные выражения вычислятся при компиляции.

А можно как-нибудь так, чтобы 240 хранилось в int8 или int16, а то int32 как-то накладно выглядит.

P.S: На случай, если они перестанут быть константными или поучаствуют ещё-где-нибудь.

Можно через дефайн. Но потребуется явно приводить их к соответствующему типу для исключения переполнения.
А можно и наоборот приводить к байту или слову в требуемых случаях, когда константы объявлены как UL.
Но проблема ИМХО надуманная. Как это так, они вдруг перестанут быть константами?
Ну а с квалификатором ststic const константы не занимают память вовсе, пока в программе не производится взятие адреса этой константы.

Вот он, момент истины спасибо

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

Как правило, все константы задаются просто через дефайны:

У меня и так его (оверхеда) нет и без статиков, бо С++. И указывать суффикс UL тоже излише. Тип и так четко и однозначно указан.


Можно объявить const uint8_t Y_SIZE = 240;. На дальнейшее использование это не повлияет - в использующем выражении операнды все равно будут приведены к нужному типу.



Задавались. А нынче рулят константы. И нет ни одной причины использовать тут макросы. Зато причин не использовать предостаточно.

dxp Хм, а если С без плюсов?. Статический массив как бы не объявляется в таком случае.

Ну по-моему бе плюсов там идёт глобальная линковка по умолчанию, а в плюсах наоборот статик подразумевается...если я ничего не путаю.....

sigmaN Скорее всего моя терминология хромает, я имею ввиду элеметарную ситуацию:
В Си не соберётся.

аа, об этом я уже как-то упоминал.
Не собирается(как мне объяснили) потому, что объявление и инициализация - это разные этапы компиляции. Т.е. на момент первого прохода компилятор ещё ничего не знает о том, что x_size == 10. Выходом из этой ситуации может быть enum или #define

Как там с подобными конструкциями в плюсах - не знаю....может там и соберется.

да нет, скорее всего я просто Вас неправильно понял и дал ответ на совершенно иной вопрос

тут найдете много чего полезного http://electronix.ru/forum/index.php?showtopic=68225

Не понял вопроса. Если на С и хочется, чтобы в память не легло, то надо объявлять как static. При этом если нет попыток взятия адреса, то и причин у компилятора заводить под это память не будет - все значения он сможет вычислить на этапе компиляции.

dxp в привидённом выше примере static не спасает. Я обычно все глобальные переменные static'ом обзываю (от греха подальше). Ну да ладно, читаю вышерекомендованную тему, делаю выводы. Тут это всё же офтоп.

Вы имеете ввиду глобальные константы? Ибо переменная в модуле становится локальной... Ну и все подряд константы делать статическими тоже неверно...


Ну так а тож
Ещё как повлияет, если в int не впишется...
+1

Не, я имел ввиду переменные и локальность это только плюс(практически плюсплюс ). Const'антами пользуюсь пока крайне умеренно. Тут больше вопрос не "что использовать define или const", а "Си или С++".