将size_t替换为unsigned long的缺点是什么?

10
我正在工作的这个库需要在32位和64位机器上使用;由于64位机器上的unsigned int != size_t,所以我有很多编译警告。
将所有的unsigned int和size_t都替换为unsigned long是否存在任何弊端?虽然它看起来不太优雅,但是在我们的情况下,内存不是什么大问题... 我想知道是否有可能由这样的replace all操作创建任何错误/不希望的行为等(您可以给出例子)?谢谢。

6
一个缺点是,64位Windows上的size_tunsigned long long,因为long只有32位(即使在64位模式下也是如此)。 - Bo Persson
5
为什么不做相反的事情,用std::size_t替换所有相关的出现? - Konrad Rudolph
2
@YuccaV 不,指针(以及某种程度上的intptr_t)应该表示地址。size_t 表示对象大小或对象(数组)中的索引。 - Angew is no longer proud of SO
2
除了Angew所说的,也许在未来size_t会变成128位,你最终会遇到同样的问题。size_t存在的整个原因是让你不必担心容器内部使用的类型。 - Spook
2
@Spook ISO C要求size_t作为无符号整数类型。如果将其更改为有符号整数类型,几乎什么都无法正常工作。 - FrankHB
显示剩余3条评论
4个回答

10
什么警告?我能想到最明显的是“缩小转换”警告,也就是说你正在将size_t赋值给unsigned int,并且得到一个警告,表示可能会丢失信息。
unsigned long替换size_t的主要缺点是,不能保证unsigned long足够大,以包含每个可能的size_t值,在Windows 64上它不够大。所以你可能仍然会遇到警告。
适当的修复方法是,如果你将size_t分配给变量(或数据成员),你应该确保变量的类型足够大,以包含任何size_t值。这就是警告的意义所在。所以你不应该切换到unsigned long,你应该将这些变量切换为size_t
相反,如果你有一个变量不需要足够大来容纳任何大小,只需要足够大来容纳unsigned int,那么首先就不要使用size_t
两种类型(size_tunsigned int)都有有效的用途,因此任何不加区分地将它们的所有用法替换为其他类型的方法一定是错误的 :-) 实际上,你可以用size_tuintmax_t替换所有内容,在大多数程序中这将是可以的。例外情况是,代码依赖于使用与int相同大小的无符号类型,等等,这样大型类型会破坏代码。

5
标准对于像int和long这样的类型的大小没有做出很多保证。size_t保证足够大以容纳任何对象,并且所有std容器都使用size_t。完全有可能将long定义为小于size_t,或者使long的大小受编译选项的影响。为了安全起见,最好坚持使用size_t。
另一个要考虑的标准是,size_t承载着一种含义——“这个东西用来存储大小或索引”。它使代码稍微更具自我说明性。

4
如果您在应该使用 size_t 的地方使用它,并将其替换为 unsigned long,则会引入新的警告。
例如:
size_t count = some_vector.size();

size_t替换为unsigned long,如果它们有所不同,那么您将引入一个新的警告(因为some_vector.size()返回一个size_t - 实际上是一个std:::vector<something>::size_type,但在实践中应该评估为相同)。


我可能会得到更多的警告,但是升级会引起真正的问题(例如错误)吗? - Yulia V
3
在任何认真对待自身的程序中,警告都是真正的问题。 - Angew is no longer proud of SO
这取决于你的代码。例如,如果你计算偏移量的差异并将它们与零进行比较,使用无符号数可能会导致负数转换为无符号数,这应该接近该类型无符号值可以表示的最大范围(0x11111111或类似值)。基本上这取决于你的代码库。Angew的观点是正确的:你最好将编译器设置为对警告具有零容忍度(对于gcc来说,这是“-Werror”选项)。 - utnapistim

0
可能是将 long 型误认为是 8 字节的 unsigned long 型,这样 (unsigned int) -1 != (unsigned long) -1 ,下面的代码可能会断言失败。
unsigned int i = string::npos;
assert(i == string::npos);

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接