我对size_t的理解是，它足够大，可以容纳任何（整数）值，您可能认为它需要保持。 （也许这是一个不好的解释？）C++：是否有任何理由使用uint64_t，而不是size_t
例如，如果您使用类似for循环遍历向量中的所有元素，size_t通常是64位长（或至少在我的系统上）为了它可以从vector.size（）中保存所有可能的返回值。
或者至少，我认为这是正确的？
因此，没有任何理由使用，而不是B：
答：for(uint64_t i = 0; i < v.size(); ++ i)
B：for(size_t i = 0; i < v.size(); ++ i)
如果我错了，我的解释，或者你有更好的解释，请随时编辑。
编辑：我应该补充一点，我的理解是，size_t行为像一个正常的无符号整数 - 也许这是不正确的？
正确的情况是for(std::vector::size_type i ...。
对于通过一个载体，或者诸如此类的东西迭代的目的，你将很难推到寻找到size_t不够大的情况下，和uint64_t是，
当然，在32位机器，size_t通常是32位，但你可能想要处理大于40亿的数字，这将需要超过32位，这当然是一个用例uint64_t。换言之，uint64_t保证是64位，size_t在所有机器/体系结构中不是64位。
size_t是返回式sizeof。
该标准说它是一些无符号整数类型的typedef，并且足够大以容纳任何可能的对象的大小。
但它并没有要求它是更小，更大还是与uint64_t（固定宽度的64位无符号整数的typedef）相同的大小，在后一种情况下它也不是相同的类型。
因此，使用size_t其中语义正确。
喜欢的std::vector<T>的size()（std::vector得到它的从使用分配器size_type，std::allocator<T>使用size_t）。
没有冒犯，但'std :: vector
是的，而且来自分配器。 – Deduplicator 2018-02-18 17:09:39
uint64_t保证是64位。如果你需要64位，你应该使用它
size_t不能保证是64位，在未来的一台机器可能是128位。所以，关键字uint_64其保留的:)
应该“保证是” – dtech 2015-02-23 23:51:45
std::size_t被定义为无符号整数类型。它的长度取决于平台。 v.size()将始终返回std::size_t类型的值，因此选项B总是正确的。
不，size_t与“持有您可能期望它需要保留的任何整数值”完全没有关系。你从哪里得到这个？
size_t应该足够大以容纳给定实现中的任何连续对象的字节大小。从概念上讲，这比“任何整数值”少得多。该语言并不保证您可以创建占用整个可寻址存储的对象，这意味着size_t在概念上不足以保存可寻址的内存字节数。
如果您想将任意整数值与内存大小相匹配，那么适当的类型将是uintptr_t，这在概念上大于size_t。但我认为没有任何理由将“任何整数值”与记忆特征联系在一起。例如。即使uintptr_t大于size_t，但不能保证足够大以保持平台文件系统中最大文件的大小。
您可以使用size_t迭代std::vector的元素的原因是该向量在内部基于数组。数组是连续的对象，这就是为什么它们的大小被size_t覆盖。但是一旦考虑到非连续的容器，如std::list,size_t不再保证足以测量或索引这些容器。
uint64_t可以更容易大于size_t。但很有可能您必须使用不适合uint64_t的整数值。
'std :: malloc'和'std :: allocator'也使用'std :: size_t'。 – tmlen 2015-02-23 23:49:36
即使'uintptr_t'可能太小。由于OP描述中的值没有限制...... – Deduplicator 2015-02-23 23:50:06
@tmlen：他们这样做是因为他们分配*连续的*内存块，即他们分配字节数组。对他们来说，使用'size_t'完全合适。 – AnT 2015-02-23 23:51:08
如果您需要确保您的int无论出于何种原因（通常是字节操作）都是64位。 'size_t'可以根据您的系统和编译选项而有所不同 – 2015-02-23 23:37:09
'size_t'不能保证是64bit – dtech 2015-02-23 23:46:56
如果您在32位目标上使用'uint64_t'，那么性能可能会远远低于最佳性能。 – sharptooth 2016-03-15 07:04:22