在x64上是否需要int？

Question

如前所述，针对x64的C代码应始终使用size_t而不是int来计算计数和数组索引等内容。

鉴于此，在整个代码库中，将size_t（typedef'd更短）标准化而不是int作为通常的整数类型，可以说更简单，更不容易出错。

有什么我想念的吗？假设您不需要有符号整数，并且您不存储大型小整数数组（其中使用32位而不是64位可以节省内存），是否有任何理由使用int而不是size_t？

Answer 1

我会说相反，我更喜欢你修正整数大小的东西，uint8_t ...... uint64_t（很快就会unit128_t），这些会是基础类型。所以你会知道你得到了什么。

和其他typedef一样size_t，然后别名。然后，您只需检查typedef的{​​{1}}并推断您的地址宽度，例如

而且，人们肯定需要签名类型。 但这种关系当然可以澄清。现在已经在标准中，签名类型是从无符号类型推导出来的。这可以通过强制前缀uintprt_t来明确。但肯定后来不会发生，人们在情感上过于依赖signed：）

Answer 2

正如Eli所说，int通常（并不总是）字大小，即在内存和CPU周围移动对象的首选单位。因此，即使您忽略内存使用情况，您仍可能获得更好的性能。

因此，当你不需要大于+/-（2 ^ 15 - 1）或特定宽度的范围时，我认为使用long作为“常规”有符号整数类型是非常合理的。 / p>

Answer 3

使用size_t“表示计数”和作为通用无符号整数类型几乎总是一个设计错误。 size_t仅足以保持平台支持的最大连续对象的大小。这立即意味着它可以合理地用作对象中字节的数量或数组中元素的count（或索引）（因为数组总是一个连续的对象）。但是一旦我们摆脱了连续性要求，size_t就不再适用了。您无法有意义地使用size_t来计算链接列表中的元素，因为通常情况下size_t的范围是不够的。

当然，出于此类目的使用size_t也是错误的概念。 size_t实现了对象 size 的概念，而不是对象 count 的概念。使用size_t进行数组索引仅适用于抽象数组。使用size_t索引特定于应用程序的具体数组是很奇怪的。

我个人更喜欢使用unsigned来计算和数组索引（除非我有一个更具体的类型用于此目的），假设在我的应用程序的域内类型的范围是足够的。