Почему int обычно 32-битный на 64-битных компиляторах?

Почему int обычно 32-битный на 64-битных компиляторах? Когда я начинал программировать, меня учили int, как правило, той же ширины, что и базовая архитектура. И я согласен с тем, что это также имеет смысл, я считаю логичным, что неопределенное целочисленное значение ширины будет таким же широким, как и базовая платформа (если мы не говорим о 8 или 16-разрядных машинах, где такой небольшой диапазон для int будет едва ли применим).

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

Ответ 1

Плохие варианты со стороны разработчиков?

Серьезно, согласно стандарту, "Plain ints имеет естественный размер, предложенный архитектурой исполнения окружение ", что означает 64-разрядный int на 64-битной машина. Можно легко утверждать, что все остальное не-совместимый. Но на практике проблемы сложнее: переключение с 32 бит int на 64 бит int не позволит большинство программ для обработки больших наборов данных или что угодно (в отличие от переключение с 16 бит на 32); большинство программ, вероятно, сдерживается другими соображениями. И это увеличило бы размера наборов данных и, таким образом, уменьшить местность и замедлить программа вниз.

Наконец (и, вероятно, самое главное), если int было 64 бита, short должен быть либо 16 бит, либо 32 бита, и у вас не было способа указать другого (кроме с typedefs в <stdint.h>, и намерение состоит в том, что эти следует использовать только в исключительных обстоятельствах). Я подозреваю, что это была главная мотивация.

Ответ 2

История, компромиссы и решения объясняются The Open Group на http://www.unix.org/whitepapers/64bit.html. Он охватывает различные модели данных, их сильные и слабые стороны, а также изменения, внесенные в спецификации Unix для поддержки 64-битных вычислений.

Ответ 3

int до 32 бит на большинстве основных архитектур настолько долго, что их изменение до 64 бит, вероятно, вызовет больше проблем, чем решает.

Ответ 4

Потому что нет никакого преимущества для большого количества программного обеспечения, чтобы иметь 64-битные целые числа.

Использование 64-битного int для вычисления вещей, которые могут быть вычислены в 32-битовом целочисленном (и для многих целей достаточно до 4 миллиардов (или +/- 2 миллиарда)), и сделать их больше не будет помогите что-нибудь.

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

int - натуральный размер машинного слова не является чем-то, что предусмотрено стандартом С++. В те времена, когда большинство машин, где было 16 или 32 бит, имело смысл сделать это либо 16, либо 32 бит, потому что это очень эффективный размер для этих машин. Когда дело доходит до 64-битных машин, это больше не помогает. Таким образом, пребывание с 32 бит int имеет больше смысла.

Изменить: Интересно отметить, что, когда Microsoft перешла на 64-разрядную версию, они даже не сделали long 64-bit, потому что это сломало бы слишком много вещей, которые полагались на long как 32-битное значение (или, что более важно, они имели куча вещей, которые полагались на long как 32-битное значение в их API, где иногда клиентское программное обеспечение использует int, а иногда и long, и они не хотели, чтобы это прерывалось).

Ответ 5

Основная причина - обратная совместимость. Кроме того, уже существует 64-битный целочисленный тип long, а также для типов float: float и double. Изменение размеров этих базовых типов для разных архитектур будет только усложнять. Более того, 32-разрядное целое отвечает множеству потребностей в терминах диапазона.

Ответ 6

Я изначально написал это в ответ на этот вопрос. В то время как я немного изменил его, он во многом такой же.

Для начала можно использовать обычные целые числа шире, чем 32 бита, как говорится в проекте C++ :

Примечание. Предполагается, что обычные целые числа имеют натуральный размер , предложенный архитектурой среды выполнения; другие подписанные целочисленные типы предоставляются для удовлетворения особых потребностей. - Конечная нота

^{Emphasis mine}

Казалось бы, это говорит о том, что на моей 64-битной архитектуре (и на всех остальных) обычный int должен иметь 64-битный размер; что размер, предложенный архитектурой, верно? Однако я должен утверждать, что естественный размер даже для 64-битной архитектуры составляет 32 бита. Цитата в спецификации в основном там, где желательны 16-битные обычные целочисленные значения - это минимальный размер, допустимый спецификациями.

Самым важным фактором является соглашение: переход от 32-битной архитектуры с 32-битным простым int и адаптация этого источника для 64-битной архитектуры будет проще, если вы оставите его 32-битным, как для разработчиков, так и для пользователей двумя различными способами:

Во-первых, чем меньше различий между системами, тем проще для всех. Несоответствия между системами были лишь головной болью для большинства программистов: они только усложняют выполнение кода в разных системах. Это даже добавит к относительно редким случаям, когда вы не сможете сделать это на компьютерах с одинаковым распределением, только 32-битным и 64-битным. Тем не менее, как отметил Джон Кугельман, архитектуры перешли с 16-битного на 32-битное простое int, и сегодня можно снова столкнуться с трудностями, которые связаны с его следующим пунктом:

Более значимым компонентом является разрыв, который он может вызвать в целочисленных размерах или в новом типе. Поскольку sizeof(short) <= sizeof(int) <= sizeof(long) <= sizeof(long long) находится в фактической спецификации, разрыв будет принудительным, если обычный int будет перемещен в 64 бита. Это начинается со смещения long. Если для простого int задано значение 64 бита, то ограничение sizeof(int) <= sizeof(long) заставит long составлять как минимум 64 бита, и оттуда будет свойственный разрыв в размерах. Так как long или обычный int обычно используются как 32-разрядное целое число, и ни один из них не может теперь, у нас есть только один тип данных, который мог бы, short. Поскольку short имеет минимум 16 битов, если вы просто отбросите этот размер, он может стать 32 битами и теоретически заполнить этот пробел, однако short предназначен для оптимизации под пространство, поэтому его следует сохранить таким образом, и есть варианты использования для малых, 16-битных, целых чисел. Независимо от того, как вы расположите размеры, есть потеря ширины и, следовательно, сценарий использования для int полностью недоступен. Большая ширина не обязательно означает, что это лучше.

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

В качестве примечания: если ваше приложение несовместимо с> 32-битным целым числом, вы можете использовать static_assert(sizeof(int) * CHAR_BIT <= 32, "Int wider than 32 bits!");. Однако, кто знает, может быть, спецификации изменятся, и будут реализованы 64-битные обычные целочисленные значения, поэтому, если вы хотите быть в будущем, не делайте статического утверждения.

Ответ 7

Так как никто еще не указал на это.

int гарантируется от от -32767 до 32767 ( 2^16). Это требуется стандартом. Если вы хотите поддерживать 64-битные номера на всех платформах, я предлагаю использовать правильный тип long long, который поддерживает (-9223372036854775807 до 9223372036854775807).

int разрешено быть чем угодно, если оно обеспечивает минимальный диапазон, требуемый стандартом.

Ответ 8

В стандарте C + + не указано, сколько памяти должно использоваться для типа int, указывается, сколько памяти должно использоваться, по крайней мере, для типа int. Во многих средах программирования на 32-битных переменных указателя "int" и "long" имеют длину 32 бита.