C++:是否有理由使用uint64_t而不是size_t

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

size_t不能保证是64位；在未来的机器中可能是128位。因此，关键字uint_64被保留：）

size_t是sizeof的返回类型。

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

因此，在语义正确的地方使用size_t
类似于std::vector<T>的size()（std::vector从使用的分配器中获得size_type，std::allocator<T>使用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与"持有任何您可能期望它持有的整数值"完全没有联系。你从哪里得到的？

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

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

之所以可以使用size_t来迭代std::vector的元素，是因为向量在内部基于数组。数组是连续的对象，这就是size_t覆盖数组大小的原因。但是，一旦考虑到像std::list这样的非连续容器，就不能再保证size_t足以测量或索引这些容器。

CCD_ 35可以更容易地大于CCD_ 36。但是，您可能不得不使用不适合uint64_t的整数值。

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