Почему компиляторы C указывают, что long должен быть 32-битным, а long long - 64-битным?

Question

Разве не имело бы смысла делать длинные 64-битные и резервировать длинные длинные, пока 128-битные числа не станут реальностью?

Answer 1

Да, это имеет смысл, но у Microsoft были свои причины для определения "long" как 32-битных.

Насколько я знаю, из всех основных систем сейчас Windows является единственнойОС, где "long" - 32-битнаяВ Unix и Linux он 64-битный.

Все компиляторы для Windows будут компилировать "длинные" в 32-битные версии Windows для обеспечения совместимости с Microsoft.

По этой причине я избегаю использования"int" и "long".Иногда я буду использовать «int» для кодов ошибок и логических значений (в C), но я никогда не буду использовать их для любого кода, который зависит от размера типа.

Answer 2

Стандарт c НЕ определил длину в битах примитивного типа данных, а только наименьшую длину в битах. Таким образом, компиляторы могут иметь параметры битовой длины примитивных типов данных. При определении длины битов каждого примитивного типа данных разработчик компилятора должен учитывать несколько факторов, включая архитектуру компьютера.

вот несколько ссылок: http://en.wikipedia.org/wiki/C_syntax#Primitive_data_types

Answer 3

По историческим причинам. В течение долгого времени (каламбур) «int» означало 16-битный; следовательно "длинный" как 32-битный. Конечно, времена изменились. Следовательно "длинный длинный":)

PS:

GCC (и другие) в настоящее время поддерживают 128-битные целые числа как "(u) int128_t".

PPS:

Вот обсуждение того, почему люди в GCC приняли решения, которые они сделали:

http://www.x86 -64.org / pipermail / обсуждение / 2005-август / 006412.html

Answer 4

d 32-битные микрокомпьютеры определяют «char» как 8 бит, «short» как 16 бит и «long» как 32 бита. Единственное различие между ними заключается в том, является ли значение int 16 битами или 32.

В то время как 32-разрядный или больший процессор может использовать «int» в качестве 32-разрядного типа, оставляя «long» доступным как 64-разрядный тип, существует существенный корпус кода, который ожидает, что «long» будет 32 бита В то время как Стандарт C добавил типы «фиксированного размера» в 1999 году, в Стандарте есть и другие места, в которых все еще используются «int» и «long», такие как «printf». В то время как C99 добавил макросы для обеспечения

Answer 5

Еще со времен первого компилятора C для перепрограммируемого микрокомпьютера общего назначения часто в коде было необходимо использовать типы, которые содержат ровно 8, 16 или 32 бита, но до 1999 года стандарт не применялся.t явно предоставить программам возможность указать это.С другой стороны, почти все компиляторы для 8-битных, 16-битных и 32-битных микрокомпьютеров определяют "char" как 8 бит, "short" как 16 бит и "long" как 32 бит.Единственное различие между ними заключается в том, является ли значение int 16-разрядным или 32-битным.

В то время как 32-разрядный или более мощный ЦП может использовать «int» в качестве 32-разрядного типа, оставляя «long» доступным как 64-битного типа, существует существенный корпус кода, который ожидает, что «long» будет 32-битным.В то время как Стандарт C добавил типы «фиксированного размера» в 1999 году, в Стандарте есть и другие места, в которых все еще используются «int» и «long», такие как «printf».В то время как C99 добавил макросы для предоставления правильных спецификаторов формата для целочисленных типов фиксированного размера, существует значительный объем кода, который ожидает, что «% ld» является допустимым спецификатором формата для int32_t, поскольку он будет работать практически на любых 8-битных, 16-битная или 32-битная платформа.

Имеет ли смысл иметь "длинный" 32-битный, из уважения к существующей кодовой базе, уходящей в прошлое на десятилетия или 64-битный, чтобыизбегать необходимости более подробных "long long" или "int64_t" для идентификации 64-битных типов - это, вероятно, вызов для суждения, но, учитывая, что новый код должен, вероятно, отдавать предпочтение использованию типов указанного размера, когда это практически возможно, я неуверен, что я вижу неоспоримое преимущество в создании «длинных» 64 битов, если только «int» также не 64 бит (что создаст еще большие проблемы с существующим кодом).

Answer 6

C99 N1256 стандартный чертеж

Размеры long и long long определены реализацией, все, что мы знаем:

• минимальный размер гарантирует
• относительные размеры между типами

5.2.4.2.1 Размеры целочисленных типов <limits.h> дает минимальные размеры:

1 [...] Их определяемые реализацией значения должны быть равны или больше по величине (абсолютное значение) показанным [...]

• UCHAR_MAX 255 //2 8 - 1
• USHRT_MAX 65535 // 2 16 - 1
• UINT_MAX 65535 // 2 16 - 1
• ULONG_MAX 4294967295 // 2 32 - 1
• ULLONG_MAX 18446744073709551615 // 2 64 - 1

6.2.5 Типы , затем говорит:

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

и 6.3.1.1 Логические значения, символы и целые числа определяет относительные ранги преобразования:

1 Каждый целочисленный тип имеет целочисленный ранг преобразования, определяемый какследует:

• Ранг long long int должен быть больше ранга long int, который должен быть больше ранга int, который должен быть больше ранга short int, который долженбыть больше, чем ранг знака со знаком.
• Ранг любого целого типа без знака должен равняться рангу соответствующего целого типа со знаком, если таковой имеется.
• Для всех целочисленных типов T1, T2,и T3, если T1 имеет больший ранг, чем T2, и T2 имеет больший ранг, чем T3, тогда T1 имеет больший ранг, чем T3