Делать int
максимально широким — не лучший выбор. (Выбор делают разработчики ABI.)
64-битная архитектура, такая как x86-64, может эффективно работать с int64_t
, поэтому вполне естественно, что long
будет 64-битным. (Microsoft сохранила long
как 32-битную в своем ABI x86-64 по различным причинам переносимости, которые имеют смысл, учитывая существующие кодовые базы и API. Это в основном не имеет значения, потому что переносимый код, который действительно заботится о размерах типов, должен использовать int32_t
и int64_t
вместо того, чтобы делать предположения. о int
и long
.)
Наличие int
вместо int32_t
на самом деле делает код лучше и эффективнее во многих случаях. Массив из int
использует только 4 байта на элемент и имеет только половину объема кэш-памяти массива из int64_t
. Кроме того, для x86-64 по умолчанию используется 32-битный размер операнда, поэтому для 64-битных инструкций требуется дополнительный байт кода для префикса REX. Таким образом, плотность кода лучше для 32-битных (или 8-битных) целых чисел, чем для 16- или 64-битных. (Ссылки на документы и руководства см. на вики x86. / образовательные ресурсы.)
Если программе для корректной работы требуются 64-битные целочисленные типы, она не будет использовать int
. (Сохранение указателя в int
вместо intptr_t
является ошибкой, и мы не должны ухудшать ABI, чтобы приспособить такой неработающий код.) Программист, пишущий int
, вероятно, ожидал 32-битного типа, поскольку большинство платформ работают именно так. (Стандарт, конечно, гарантирует только 16 бит).
Поскольку нет никаких ожиданий, что int
будет 64-разрядным в целом (например, на 32-разрядных платформах), а создание 64-разрядного режима сделает некоторые программы медленнее (и почти ни одно из них не ускорится), int
является 32-разрядным в большинстве 64-разрядных ABI.
Кроме того, должно быть имя для 32-битного целочисленного типа, чтобы int32_t
было typedef
для.
person
Peter Cordes
schedule
21.03.2016