当前是否有使用C++编译器的系统，其中int类型的宽度超过32位？

Question

当前是否有使用C++编译器的系统，其中int类型的宽度超过32位？

28

C++标准仅规定int必须至少为16位宽。根据cppreference的说法，它通常是16位或32位：

data model       int width in bits
----------------------------------
C++ standard     at least 16
LP32             16
ILP32            32
LLP64            32
LP64             32
有没有当前使用的C++编译器系统示例，其中int的位宽超过32位？所谓当前使用是指例如某些旧64位Unix系统（例如Cray上的Unicos）中出现的ILP64（8/8/8：int、long和pointer均为64位）。最好是正在积极开发/研究的现代系统，例如用于科学计算的具有64位int的系统。我不是在寻找20年未被触及的遗留代码，也不是只用来玩耍的系统，或者只有两家公司使用的老系统，他们太吝啬升级。

- ruohola

1

就此而言，浏览GCC源代码，所有架构的“int”类型似乎都是16或32位...除了一些小型Atmel AVR芯片，它只有8位！ - rodrigo

1

嗯...“非过时”的确会引起主观意义。也许可以将其重新表述为更客观的词语，比如“当前使用”或“未被废弃的”？要证明一个系统没有被废弃，你只需要列举一个仍在使用它的实体即可。这不会改变问题的意图，但可能会改变问题的感知方式。 - JaMiT

1

我肯定在过去5年中的某个地方使用了gcc / clang / msvc，它将int作为64位输出（这让我感到惊讶）。真正的问题是 - 你为什么要问？因为如果需要知道答案（除了好奇心），那就意味着你已经做错了一些事情。如果需要32位int，请使用std :: int32_t。int是一个“普通”的整数，足够大处理常见的数学结果，并且绑定将来某个时候变成64位，因此依赖它永远是32位是一个错误。 - Radosław Cybulski

2

如果有人找到了回答这个问题的东西，他们也应该在标准委员会关心的异域架构中添加一个答案。 - Shafik Yaghmour

1

据我所知，当将一些网络测试软件移植到Cray J90上的Unicos时，我发现int令人惊讶。它有8个字节...足够不寻常了，但是INT_MAX的值比其存储空间小！ int和long之间的区别在于速度。 int值被限制为适合浮点硬件的有效位。非常独特的硬件设计。处理完整的64位整数运算（C“long”）是一个缓慢的软件操作。 https://yarchive.net/comp/cray_integers.html 暗示了这一点。 - gps

显示剩余9条评论

2个回答

2

我仍然认为这是一个主观的问题。虽然Univac并不常见，但仍有一些工作示例，例如德国法兰克福附近的technikum29生活计算机博物馆中的Univac 9400。人们仍在维护其正常运行。

2002-2008年的《新C标准（摘录材料）》表示：

常见的实现最常大于下面所示值的值是适用于类型int的值。在托管实现中，它们通常与类型long的相应值相同。在独立实现中，处理器的效率问题通常决定使用较小的数字范围，因此通常使用此处显示的最小值。用于相应字符、short、long和long long类型的值通常与标准中给出的值相同。

联合利华A系列[5]不仅使用符号大小，而且对于所有非字符整数类型都具有单一大小（六个字节）。该供应商的实现尚未支持长长类型。

#define SHRT_MIN (-549755813887)
#define SHRT_MAX 549755813887
#define USHRT_MAX 549755813887U
#define INT_MIN (-549755813887)
#define INT_MAX 549755813887
#define UINT_MAX 549755813887U
#define LONG_MIN (-549755813887L)
#define LONG_MAX 549755813887L
#define ULONG_MAX 549755813887UL

这种字符类型使用二进制补码表示法，占用一个字节。Unisys e-@ction应用程序开发解决方案（曾被称为通用编译系统UCS）的C编译器有9位字符类型——18位short、36位int和long，以及72位long long。REF：http://c0x.coding-guidelines.com/5.2.4.2.1.pdf。最初的回答。

- AlwaysLearning

1

嗯，我认为没有人会将“博物馆中的一台工作电脑”归类为业内相关。而且据我所见，您提供的参考链接只是在谈论C编译器，而不是C++编译器。 - ruohola

@ruohola 这正是你的问题带有主观性的原因。我满足了你的条件，但你还在争论这一点。“过时的形容词。不再生产或使用；过时。”Univac仍在使用，因此它并不过时。 - AlwaysLearning

2

我已经对我的问题进行了一些修改，我认为您也会同意现在它没有任何主观色彩。 - ruohola

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- David Archibald · Accepted Answer

请注意，这个答案旨在挑战框架; 即使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位纯整数，所以如果您想要未来的保障，请勿执行静态断言。