请注意,这个答案旨在挑战框架; 即使64位操作系统通常不需要> 32位,因为有几个原因。这意味着一个团队创建操作系统时很少会考虑这些问题,更不可能是过时的。我希望能找到一个更直接的答案,但我认为这至少证明了主要操作系统的决策。
首先,您是正确的,
C ++草案允许允许宽度超过32位的普通int。引用如下:
“注意:普通整数的目的是具有执行环境建议的自然大小;提供其他有符号整数类型以满足特殊需求。 —注”
这似乎表明,在我的64位架构(和其他人的)上,普通int应该具有64位大小;那是架构建议的大小,对吗?但是我必须断言,即使是64位架构的
自然大小也是32位。规范中的引用主要用于需要16位普通int的情况。
惯例是一个强大的因素,如果从具有32位普通int的32位架构转换到适合64位架构的源,则保持32位对于设计者及其两个不同用户来说都更容易:
第一点是系统之间差异越小,对每个人来说就越容易。系统之间的差异只会给大多数程序员带来麻烦:它们只会使在不同系统上运行代码更加困难。即使在使用相同发行版的计算机上,32位和64位之间也会出现相对罕见的无法运行的情况。然而,正如John Kugelman指出的那样,体系结构已经从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位纯整数,所以如果您想要未来的保障,请勿执行静态断言。
std :: int32_t
。int是一个“普通”的整数,足够大处理常见的数学结果,并且绑定将来某个时候变成64位,因此依赖它永远是32位是一个错误。 - Radosław Cybulskiint
令人惊讶。它有8个字节...足够不寻常了,但是INT_MAX的值比其存储空间小! int和long之间的区别在于速度。 int值被限制为适合浮点硬件的有效位。非常独特的硬件设计。处理完整的64位整数运算(C“long”)是一个缓慢的软件操作。 https://yarchive.net/comp/cray_integers.html 暗示了这一点。 - gps