size_t总是未签名？
作为标题：size_t总是无符号的，即对于size_t x ，是x总是>= 0 ？
是的 。 通常将其定义为以下内容（在32位系统上）：
typedef unsigned int size_t;
参考：
C ++标准第18.1节定义了size_t是在<cstddef> ，在C标准中描述为<stddef.h> 。
C标准第4.1.5节将size_t定义为sizeof运算符结果的无符号整型
根据1999年ISO C标准（C99）， size_t是一个至less16位的无符号整数types（见7.17节和7.18.3节）。
该标准还build议size_t不应该具有大于long的整数转换等级，即，如果遵循build议，则将size_t为unsigned long是没有问题的。
1989 ANSI C标准（ANSI C）没有提到最小尺寸或推荐的转换等级。
1998年的ISO C ++标准（C ++ 98）（以及C ++ 0x的当前草案）是指C标准。 第18.1节写道：
内容与标准C库头
<stddef.h>相同
根据第1.2节，这意味着由1990 ISO C标准（C90）定义的图书馆，包括1995年（C95）的第一次修订：
ISO / IEC 9899：1990第7条和ISO / IEC 9899 / Amd.1：1995第7条描述的库在下文中称为标准C库 。
关于size_t的部分应该从ANSI C：Frontmatter和section编号inheritance，C90和ANSI C的标准是相同的。 我需要一个规范修订的副本，以确保stddef.h没有任何相关的变化，但我怀疑它。 最小尺寸似乎是用stdint.h引入的，即C99。
请考虑C ++ 98第1.2节中的以下引用：
所有标准均有修改，鼓励根据本国际标准达成协议的各方研究采用下列标准最新版本的可能性。
是的，size_t保证是一个无符号types。
根据标准，它是无符号的，但是我记得一些较早的实现对typedef使用了一个签名types。
从较旧的GCC文档：
版本2.4之前的GCC的size_ttypes和版本存在潜在的问题。 ANSI C要求
size_t总是一个无符号types。 为了与现有系统的头文件兼容，GCC将stddef.hsize_t定义为系统的sys/types.h定义的types。 大多数在sys/types.h中定义size_tUnix系统将其定义为一个有符号的types。 库中的一些代码依赖于size_t是一个无符号types，如果它被签名，将无法正常工作
我不确定这是多么重要。 我的代码假设它没有签名。
size_t应该遵循与C标准相同的定义，并且在C ++标准中的几个地方暗示它是无符号的natura（特别是在分配器模板参数定义中）。
在C ++标准中，第18.1节（ISO / IEC 14882 – 第一版1998-01-01）：
表15列出了定义的types：ptrdiff_t和size_t
3内容与标准C库标题相同，但有以下更改：4在本国际标准（4.10）中，macrosNULL是实现定义的C ++空指针常量。
macros的offsetof在本标准中接受一组有限的types参数。 types应为POD结构或POD结合（第9条）。 将offsetofmacros应用于作为静态数据成员或函数成员的字段的结果是未定义的。 另请参见：5.3.3节，Sizeof节，5.7节，Additive运算符，12.5节，Free store和ISO C子条款7.1.6。
哦，这太糟糕了：
vector<MyObject> arr; Fill(arr); size_t size = arr.size(); for(size_t i = 1; i < size - 1; ++i) { auto obj = arr[i]; auto next = arr[i+1]; }
现在考虑arr为空的用例。
