C++：有什么理由使用 uint64_t 而不是 size_t答案

【问题标题】：C++: Is there any reason to use uint64_t instead of size_tC++：有什么理由使用 uint64_t 而不是 size_t
【发布时间】：2015-04-25 11:26:32
【问题描述】：

我对@987654321@ 的理解是，它足够大，可以容纳您可能期望它必须容纳的任何（整数）值。（也许这是一个糟糕的解释？）

例如，如果您使用 for 循环之类的东西来遍历向量中的所有元素，size_t 通常是 64 位长（或至少在我的系统上），以便它可以保存所有可能的返回来自 vector.size() 的值。

或者至少，我认为这是正确的？

因此，是否有任何理由使用 A 而不是 B：

答：for(uint64_t i = 0; i < v.size(); ++ i)

乙：for(size_t i = 0; i < v.size(); ++ i)

如果我的解释有误或您有更好的解释，请随时编辑。

编辑：我应该补充一点，我的理解是 size_t 的行为就像一个普通的无符号整数 - 也许这不正确？

【问题讨论】：

【解决方案1】：

uint64_t 保证为 64 位。如果你需要 64 位，你应该使用它。

size_t 不保证为 64 位；在未来的机器中可能是 128 位。因此，关键字 uint_64 由它保留 :)

【讨论】：

【解决方案2】：

size_t 是sizeof 的返回类型。

标准说它是某种无符号整数类型的 typedef，并且大到足以容纳任何可能的对象的大小。
但它并没有规定它是更小、更大还是与uint64_t（固定宽度的 64 位无符号整数的 typedef）大小相同，也没有规定它是否是相同的类型。

因此，在语义正确的地方使用size_t。
就像std::vector<T> 的size() 一样（std::vector 从使用的分配器中获取size_type，std::allocator<T> 使用size_t）。

【讨论】：

【解决方案3】：

不，size_t 与“持有您可能希望它持有的任何整数值”绝对没有关系。你从哪里得到这个？

size_t 应该足够大以容纳给定实现中任何连续对象的字节大小。从概念上讲，这远不及“任何整数值”。该语言不保证允许您创建占用整个可寻址存储空间的对象，这意味着size_t 在概念上甚至不足以容纳可寻址内存字节数。

如果您想将“任何整数值”与内存大小联系起来，那么合适的类型是uintptr_t，它在概念上大于size_t。但我看不出有任何理由将“任何整数值”与内存特性联系起来。例如。即使uintptr_t 比size_t 大，也不能保证它足够大以容纳平台文件系统中最大文件的大小。

您可以使用size_t 迭代std::vector 的元素的原因是vector 在内部基于数组。数组是连续对象，这就是size_t 涵盖它们的大小的原因。但是，一旦考虑到不连续的容器，例如std::list，就不再保证size_t 足以测量或索引此类容器。

uint64_t 可以更容易地大于size_t。但很有可能您必须使用不适合 uint64_t 的整数值。

【讨论】：

【解决方案4】：

std::size_t 被定义为无符号整数类型。它的长度取决于平台。 v.size() 将始终返回 std::size_t 类型的值，因此选项 B 始终正确。

【讨论】：

【解决方案5】：

正确的大小写是for(std::vector::size_type i ...。

为了遍历向量或类似的东西，您将很难找到size_t 不够大而uint64_t 足够大的情况，

当然，在 32 位机器上，size_t 通常是 32 位，但您可能想要处理大于 40 亿的数字，这需要超过 32 位，这当然是一种用途—— uint64_t 的情况。换句话说，uint64_t 保证为 64 位，size_t 在所有机器/架构中不是 64 位。

【讨论】：