c - C 中的 "int"是否总是与操作系统的位数相同？

Question

在系统上，C 中的数据类型“int”是否总是与操作系统的位数相同？

谢谢!

Answer 1

不，不一定。举一个明显的例子，如果你在 64 位操作系统上使用 32 位编译器，你通常会有 32 位 int

C 标准中的要求相当低。除了最小尺寸要求外，还有 (§6.2.5/5):

A ‘‘plain’’ int object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range INT_MIN to INT_MAX as defined in the header <limits.h>).

如果您需要确定您的类型至少是 64 位，您可以使用 long long .

类似 int32_t 的类型在其他答案中已经提到。尽管经常用于其他目的，但这种类型确实适用于您需要正好 32 位宽的类型的情况，而不管这对性能有何影响。

这意味着您通常希望避免这些类型。如果您只需要确保您可以至少保存一个 64 位整数而不会溢出，long long或 int_fast64_t是一个更好的选择(对于 32 位类型之类的东西也是如此)。现在，对于 64 位类型，这不会对 64 位类型产生重大影响。

对于 32 位类型(例如)，它可能会有所不同。 int32_t必须恰好是 32 位宽，但在 64 位操作系统上运行于 64 位处理器上的 64 位进程中，64 位类型很可能比 32 位类型更快 -位类型。我已经将一些使用 int32_t 的遗留(但不是很旧)代码的速度大约提高了两倍。哪里不太合适。当时(在 32 位编译器和操作系统上)它没有引起问题，但在 64 位系统上，它强加了大量的额外工作，因为他们真正想要的是 int_fast32_t。 --最快的类型，至少支持 32 位。

同样，在未来的某个时候，我们将开始使用“大于”64 位的处理器，这似乎几乎是不可避免的。当我们这样做时，我们可能会遇到与现在 32 位类型相同的 64 位类型情况:人们已经使用过很多地方 int64_t当他们可能想要int_fast64_t ，并且他们的代码运行速度将比实际需要的慢很多，因为他们要求他们的(例如)128 位处理器将操作数屏蔽为 64 位，而不是使用处理器 native 的大小。