在size_t和unsigned int之间绘制线的位置?

我目前正在使用unsigned int一些用法将size_t转换为我多年来一直在开发的代码库。 我理解两者之间的区别,例如unsigned int可能是32位而指针和size_t可能是64位。 我的问题更多的是关于我应该使用哪一个以及人们在两者之间采用何种惯例。

很明显,内存分配应该使用size_t而不是unsigned int作为参数,或者容器类应该使用size_t作为大小和索引,就像在STL中一样。 这些是在阅读size_t vs unsigned int的好处时引用的常见情况。 但是,在进行代码库转换的过程中,我偶然发现了灰色区域的很多情况,我不确定要使用哪种情况。 例如,如果4×4矩阵行/列索引应该是size_t以保持一致性,无论索引是否在范围[0,3]中,或者屏幕/纹理分辨率应该使用size_t尽管在几千的范围内,或者通常如果合理的话预计对象的数量将在数十的范围内,我仍然应该使用size_t来保持一致性。

您使用什么样的编码约定来在unsigned intsize_t之间进行选择? 表示大小(字节或对象)或索引的所有内容是否始终都是size_t而不管合理预期的范围? 是否有一些广泛接受的size_t约定用于我可以遵循的完善的库中?

我觉得这很简单,虽然我欢迎吊索和箭头。

如果它描述了具有大小的东西,则应该使用size_t 。 (伯爵。 很多东西

我最近想到了一些遗留代码的32到64位端口,我认为size_t的关键特征是它总是足以代表整个地址空间。

您可以命名的任何其他类型(包括unsigned long)都有可能在将来的某个时刻对您的数据结构施加人为限制。 当您无法在域上定义硬的先验上限时,size_t(及其表兄ptrdiff_t)应该是数据结构构造的默认基础。

对我来说,问题是你是否使用小于建筑宽度的整数,问题是你是否可以certificate更小的尺寸就足够了。

以你的4×4矩阵为例:理论上有理由说它必须是4×4而不是5×5或8×8吗? 如果有这样的理论原因,我对较小的整数类型没有问题。 如果没有,请使用size_t或至少与此类型相同的其他类型。

我的理由是固定限制(和固定的整数大小只是引入它们的一种方式)通常是睡眠错误。 总有一天,某人可能会发现一些极端的用例,你做出的修正限制的假设并不成立。 因此,您希望避免它们出现在任何地方。 而且由于我通常不打算为较小的尺寸做一个certificate(因为它对性能毫无意义),我通常最终使用全尺寸整数。