c++ - 用 unsigned long 替换 size_t 的缺点是什么

Question

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

用'unsigned long'替换所有unsigned ints和s有什么缺点吗？size_t我很欣赏它看起来不是很优雅，但是，在这种情况下，内存不是太大的问题......我想知道这种replace all操作是否有可能产生任何错误/不需要的行为等（你能举例）？谢谢。

Answer 1

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

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

正确的解决方法是，如果将 a 分配size_t给变量（或数据成员），则应确保该变量具有足够大的类型以包含size_t. 这就是警告的全部内容。所以你不应该切换到unsigned long，你应该把那些变量切换到size_t.

相反，如果您有一个变量不需要大到足以容纳任何大小，只要足够大unsigned int，那么首先不要使用size_t它。

两种类型 (size_t和unsigned int) 都有有效的用途，因此任何不加选择地将它们的所有使用替换为其他类型的方法一定是错误的 :-) 实际上，对于大多数可以的程序，您可以使用size_tor和替换所有内容。例外情况是代码依赖于使用与 或其他大小相同的无符号类型，这样较大的类型会破坏代码。uintmax_tint

Answer 2

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

例如，平台完全有可能定义long为小于size_t，或者具有long服从编译选项的大小。为了安全起见，最好坚持size_t。

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

Answer 3

如果您size_t在应该获得 asize_t并将其替换为 的地方使用unsigned long，您将引入新的警告。

例子：

size_t count = some_vector.size();

替换size_t为unsigned long, 和 （在它们不同的程度上）你将引入一个新的警告（因为some_vector.size()返回 a size_t- 实际上是 astd:::vector<something>::size_type但实际上它应该评估为相同）。

Answer 4

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

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