Ответ 1
Пожалуйста, обратите внимание, что этот ответ задуман как каркасный вызов; что даже 64 операционные системы обычно не хотят> 32 бит из-за нескольких моментов. Это означает, что вряд ли команда приложит усилия для создания операционной системы, не приняв во внимание эти моменты и еще менее вероятно, что она не устареет к этому моменту времени. Я надеюсь, что будет найден более прямой ответ, но я думаю, что это оправдывает, по крайней мере, основные решения операционной системы.
Для начала вы правы, что черновик C++ разрешает использовать обычные целые числа, размер которых может превышать 32 бита. Цитировать:
Примечание. Предполагается, что обычные целые числа имеют натуральный размер , предложенный архитектурой среды выполнения; другие подписанные целочисленные типы предоставляются для удовлетворения особых потребностей. - Конечная нота
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-битные обычные целочисленные значения, поэтому, если вы хотите быть в будущем, не делайте статического утверждения.