Unsigned int vs. size_t

我注意到,现代C和c++代码似乎到处都在使用size_t而不是int/unsigned int——从C字符串函数的参数到STL。我很好奇这样做的原因和它带来的好处。

251016 次浏览

size_t类型是无符号整数类型,是sizeof操作符(和offsetof操作符)的结果,因此它保证足够大,可以包含系统可以处理的最大对象的大小(例如,8Gb的静态数组)。

size_t类型可能大于、等于或小于unsigned int类型,编译器可能会对它进行优化假设。

您可以在C99标准第7.17节中找到更精确的信息,该标准草案在互联网上以pdf格式提供,或者在C11标准第7.19节中以pdf草案格式提供。

size_t类型必须足够大,以存储任何可能的对象的大小。Unsigned int不需要满足这个条件。

例如,在64位系统中,int和unsigned int可能是32位宽,但size_t必须足够大,可以存储大于4G的数字

经典C语言(Brian Kernighan和Dennis Ritchie在《C编程语言》(Prentice-Hall, 1978)中描述的早期C语言方言)没有提供size_t。C标准委员会引入size_t来消除可移植性问题

在embedded.com中详细解释(有一个很好的例子)

size_t类型是sizeof操作符返回的类型。它是一个无符号整数,能够以主机上支持的任何内存范围的字节表示大小。它(通常)与ptrdiff_t相关,因为ptrdiff_t是一个有符号整数值,因此sizeof(ptrdiff_t)和sizeof(size_t)相等。

在编写C代码时,无论何时处理内存范围,总是都应该使用size_t。

另一方面,int类型基本上定义为主机可以用来最有效地执行整数运算的(有符号)整数值的大小。例如,在许多老式PC类型的计算机上,sizeof(size_t)的值将是4(字节),但sizeof(int)将是2(字节)。16位算法比32位算法更快,尽管CPU可以处理高达4 GiB的(逻辑)内存空间。

只有在关心效率时才使用int类型,因为它的实际精度很大程度上取决于编译器选项和机器架构。特别地,C标准指定了以下不变量:sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)对每种基元类型可供程序员使用的精度的实际表示没有其他限制。

注意:这与Java不同(Java实际上为'char', 'byte', 'short', 'int'和'long'类型指定了位精度)。

Size_t是指针的大小。

所以在32位或常见的ILP32(整数,长,指针)模型中,size_t是32位。 在64位或常见的LP64(长指针)模型中,size_t是64位(整数仍然是32位)

还有其他模型,但这些是g++使用的模型(至少在默认情况下)

简而言之,size_t从来不是负的,它最大限度地提高了性能,因为它被类型定义为无符号整数类型,该类型足够大(但又不太大),以表示目标平台上最大的可能对象的大小。

尺寸永远不应该是负的,size_t确实是一个无符号类型。此外,因为size_t是无符号的,所以您可以存储大约是相应有符号类型中两倍大的数字,因为我们可以使用符号位来表示大小,就像无符号整数中的所有其他位一样。当我们再获得一位时,我们就将我们所能表示的数字的范围乘以大约2的因子。

因此,您可能会问,为什么不直接使用unsigned int呢?它可能无法容纳足够大的数字。在unsigned int为32位的实现中,它所能表示的最大数字是4294967295。有些处理器(如IP16L32)可以复制大于4294967295字节的对象。

因此,您可能会问,为什么不使用unsigned long int呢?在某些平台上,这会造成性能损失。标准C要求long占用至少32位。IP16L32平台将每个32位长实现为一对16位字。在这些平台上,几乎所有32位操作符都需要两条指令,如果不是更多的话,因为它们在两个16位块中处理32位。例如,移动一个32位长的数据块通常需要两条机器指令——一条用于移动每个16位的数据块。

使用size_t可以避免这种性能损失。根据这篇精彩的文章,“类型size_t是一个类型定义,它是一些无符号整数类型的别名,通常是unsigned intunsigned long,但甚至可能是unsigned long long。每个标准C实现都应该选择足够大的无符号整数,但不能超过所需的大小,以表示目标平台上可能存在的最大对象的大小。”

这段摘自glibc手册0.02的摘录在研究这个主题时也可能是相关的:

在2.4版之前的GCC的size_t类型和版本中存在一个潜在的问题。ANSI C要求size_t始终是无符号类型。为了与现有系统的头文件兼容,GCC在stddef.h' to be whatever type the system'ssys/types.h中定义size_t为。大多数Unix系统在`sys/types.h'中定义size_t,将其定义为有符号类型。库中的一些代码依赖于size_t是无符号类型,如果它是有符号类型,则不能正确工作。

希望size_t为unsigned的GNU C库代码是正确的。size_t作为有符号类型的定义是不正确的。我们计划在2.4版中,GCC将始终将size_t定义为无符号类型,而fixincludes' script will massage the system'ssys/types.h'则不会与此冲突。

与此同时,我们通过告诉GCC在编译GNU C库时显式地为size_t使用unsigned类型来解决这个问题。' configure'将自动检测GCC使用什么类型的size_t,如果需要,将重写它。

如果我的编译器被设置为32位,size_t就是unsigned int的类型定义。如果我的编译器被设置为64位,size_t就是unsigned long long的类型定义。