用unsigned long替换size_t有什么缺点

Question

我正在处理的库需要在32位和64位机器上使用;我有很多编译器警告，因为在64位机器上unsigned int != size_t。

将所有unsigned int和size_t替换为'unsigned long'是否有任何不足之处？我很欣赏它看起来不是很优雅，但是，在这种情况下，内存不是太大的问题...我想知道是否有可能出现这样的{{1}创建的任何错误/不需要的行为等操作（你能举例）吗？感谢。

Answer 1

有什么警告？我能想到的最明显的一个是“缩小转化率”，也就是说你将size_t分配给unsigned int，并收到警告信息可能会丢失。

用size_t替换unsigned long的主要缺点是unsigned long不能保证足够大以包含size_t的所有可能值，而在Windows 64上它不够大。所以你可能会发现你仍然有警告。

正确的解决方法是，如果将size_t分配给变量（或数据成员），则应确保该变量的类型足以包含size_t的任何值。这就是警告的全部内容。因此，您不应该切换到unsigned long，您应该将这些变量切换为size_t。

相反，如果你的变量不需要大到可以保持任何大小，只要大到unsigned int，那么首先不要使用size_t

这两种类型（size_t和unsigned int）都有有效用途，所以任何方法都不加区别地取代其他类型的所有使用它们必须错误:-)其实，您可以使用size_t或uintmax_t以及大多数程序替换所有内容。例外情况是代码依赖于使用与int相同大小的无符号类型，或者其他类型，以便更大的类型破坏代码。

Answer 2

如果您在 获取size_t并将其替换为size_t的地方使用unsigned long，则会引入新的警告。

示例：

size_t count = some_vector.size();

将size_t替换为unsigned long，并且（在不同程度上）您会引入新警告（因为some_vector.size()会返回size_t - 实际上是{ {1}}但在实践中它应该评估相同）。

Answer 3

该标准对int和long等类型的大小几乎没有任何保证。保证size_t足够大以容纳任何对象，并且所有std容器都在size_t上运行。

例如，平台很可能将long定义为小于size_t，或者long的大小可能受编译选项的限制。为了安全起见，最好坚持size_t。

要考虑的另一个标准是size_t带有意义 - “这个东西用于存储大小或索引。”它使代码更加自我记录。

Answer 4

当long为8字节时，假设它是无符号的long可能是一个问题。然后（unsigned int）-1！=（unsigned long）-1，下面的代码可能有断言失败。

unsigned int i = string::npos;
assert(i == string::npos);