我目前正在将unsigned int的{{1}}的一些用法转换为我多年来一直在开发的代码库中的size_t。我理解两者之间的区别，例如unsigned int可能是32位，而指针和size_t可能是64位。我的问题更多的是关于我应该使用哪一个以及人们在两者之间采用何种惯例。
很明显，内存分配应该以{{1}}而不是size_t作为参数，或者容器类应该像STL一样使用unsigned int来进行大小和索引。这些是在阅读size_t vs size_t的好处时提到的常见案例。但是，在进行代码库转换的过程中，我偶然发现了灰色区域中的不少情况，我不确定要使用哪种情况。例如，如果4x4矩阵行/列索引应该是unsigned int以保持一致性，无论索引是否在范围[0,3]中，或者屏幕/纹理分辨率应该使用size_t，尽管范围很小千万，或者一般来说，如果合理数量的对象预计在十几个范围内，我仍然应该使用size_t来保持一致性。
您在size_t和unsigned int之间选择哪种编码约定？无论合理预期的范围如何，表示大小（字节或对象）或索引的所有内容都应始终为size_t吗？是否有一些被广泛接受的size_t惯例用于我可以遵循的成熟图书馆？
答案 0 :(得分：8)
我认为这很简单，虽然我欢迎吊索和箭头。
如果描述具有大小的内容，则应使用 size_t。 （计数。数量的东西）
答案 1 :(得分：4)
最近我想到了一些遗留代码的32到64位端口，在我看来size_t的关键特征是它总是足以代表你的整个地址空间。
您可以命名的任何其他类型（包括unsigned long）都有可能在将来的某个时刻对您的数据结构施加人为限制。 size_t（及其表兄ptrdiff_t）应该是数据结构构建的默认基础，因为您无法在域上定义硬的先验上限。
答案 2 :(得分：1)
对我来说，问题是你是否使用小于建筑宽度的整数，问题是你是否可以证明更小的尺寸就足够了。
以4x4矩阵为例：理论上有理由说明必须为4x4而不是5x5或8x8吗？如果有这样的理论原因，我对较小的整数类型没有问题。如果没有，请使用size_t或其他类型至少相同的类型。
我的理由是固定限制（和固定的整数大小只是引入它们的一种方法）通常是睡眠错误。有人，总有一天可能会发现一些极端的用例，你为确定限制而做出的假设并不成立。因此，您希望避免它们出现在任何地方。而且由于我通常不愿意为较小的尺寸做一个证明（因为它对性能毫无意义），我通常最终会使用全尺寸整数。