《C++程序设计语言》中，Bjarne Stroustrup写道：
unsigned整数类型非常适合将存储视为位数组的用途。为了表示正整数而使用unsigned而不是int来获得多一个比特位几乎从不是一个好主意。通过声明变量为unsigned来确保某些值为正数的尝试通常会被隐式转换规则所破坏。
size_t似乎是无符号的，"为了获得多一个比特位来表示正整数"。那么这是一个错误（或权衡），如果是的话，我们自己的代码中是否应该尽量减少使用它？
另一篇相关文章是Scott Meyers的接口中的有符号和无符号类型。总结起来，他建议在接口中不使用无符号整数，无论值是否始终为正数。换句话说，即使负值没有意义，你也不应该必然使用无符号整数。
size_t出于历史原因是无符号的。
在一个带有16位指针的架构中，比如“小型”模式的DOS编程，将字符串限制为32 KB是不切实际的。
因此，C标准通过所需的范围要求ptrdiff_t，即size_t的有符号对应类型和指针差异的结果类型，有效地为17位。
这些原因仍然可以适用于嵌入式编程领域的某些部分。
然而，在现代的32位或64位编程中，它们并不适用，更重要的考虑是 C 和 C++的不幸的隐式转换规则使得无符号类型变成了Bug的引发者，当它们用于数字（因此，算术运算和大小比较）时。以20/20的远见，我们现在可以看到，采用那些特定的转换规则，例如string( "Hi" ).length() < -3 实际上是完全不可行的，相当愚蠢的。但是，这个决定意味着在现代编程中，采用无符号类型来表示数字具有严重的劣势和没有优势 - 除了满足那些认为unsigned是一种自描述类型名称，而没有想到typedef int MyType的感觉。
总之，这不是一个错误。它是出于当时非常合理、实用的编程原因做出的决定。它与将期望从像Pascal这样的检查边界的语言转移到C++无关（尽管这是一个谬论，但是非常普遍，即使有些人从未听说过Pascal）。
string( "Hi" ).length() < -3 进行警告，但不会对两个有符号整数的比较发出警告；如果 size_t 被定义为有符号整数，你的生活不会变得更轻松，你只会犯不同类型的错误。 - Lie Ryansize_t x = 0; for(size_t i=10; i>=x; --i) {} - 你的呢？ - Benjamin Lindley将索引类型设为无符号的原因之一是为了与C和C++的半开区间偏好对称。如果您的索引类型将是无符号的，那么将大小类型也设为无符号会更方便。
在C语言中，您可以有一个指向数组的指针。有效的指针可以指向数组的任何元素或数组末尾的下一个元素。它不能指向数组开头前面的任何元素。
int a[2] = { 0, 1 };
int * p = a; // OK
++p; // OK, points to the second element
++p; // Still OK, but you cannot dereference this one.
++p; // Nope, now you've gone too far.
p = a;
--p; // oops! not allowed
C++同意并扩展了这个想法，以适用于迭代器。
反对使用无符号索引类型的论点经常举出从后往前遍历数组的例子，代码通常看起来像这样：
// WARNING: Possibly dangerous code.
int a[size] = ...;
for (index_type i = size - 1; i >= 0; --i) { ... }
只有当index_type为有符号数时，此代码才有效，该参数用作索引类型应为有符号数（并且通过延伸，大小也应为有符号数）的论据。
那个论点是不令人信服的，因为那段代码是非惯用语法。如果我们尝试使用指针而不是索引重写此循环，请看会发生什么：
// WARNING: Bad code.
int a[size] = ...;
for (int * p = a + size - 1; p >= a; --p) { ... }
size为0时的问题，我们在迭代结束时会出现一个问题，因为我们生成了一个无效指针，它指向第一个元素之前的位置。即使我们从未尝试解引用该指针，这也是未定义的行为。int a[size] = ...;
for (int * p = a + size; p != a; ) {
--p;
...
}
许多人会觉得这很不舒服，因为递减现在在循环体中而不是在头部，但这就是当你的for语法主要设计用于半开区间的正向循环时所发生的事情。(反向迭代器通过延迟递减来解决这种不对称性。)
现在，类比地说，基于索引的解决方案变成了:
int a[size] = ...;
for (index_type i = size; i != 0; ) {
--i;
...
}
index_type 是有符号的还是无符号的，这种方法都可以使用。但是无符号的选择会产生更符合习惯的指针和迭代器版本的代码映射。无符号也意味着我们将能够访问序列中的每个元素，与指针和迭代器一样，我们不需要放弃我们可能范围的一半来表示非常规值。在一个64位的世界里，这并不是一个实际的问题，但在16位嵌入式处理器或建立一个抽象容器类型用于稀疏数据覆盖大范围时，它可能是一个非常真实的问题，这仍然可以提供与本机容器相同的API。另一方面...
迷思1：std::size_t是无符号的，是因为不再适用的遗留限制。
这里通常有两个“历史”原因：
sizeof返回std::size_t，自C语言时代以来就一直是无符号的。但是，尽管这些原因非常古老，但它们实际上并没有被归类为历史。
sizeof仍然返回一个无符号的std::size_t。如果您想与sizeof或标准库容器进行交互操作，您将不得不使用std::size_t。
大小和索引不仅仅是为了内存。您的地址空间可能有限，但您可能会处理比您的地址空间大得多的文件。虽然您可能没有一个超过2GB的字符串，但您可以轻松地拥有一个超过2G位的位集。而且不要忘记为稀疏数据设计的虚拟容器。
迷思3：您总是可以使用更宽的有符号类型。
并非总是如此。对于一个或两个局部变量，您可以使用std::int64_t（假设您的系统有一个）或signed long long，并且可能编写完全合理的代码。（但您仍然需要一些显式转换和两倍的边界检查，否则您将不得不禁用一些编译器警告，这可能会提醒您在代码其他地方存在错误。）
但是如果您正在构建一个大型索引表，怎么办？当您只需要一个位时，您真的想要每个索引额外两个或四个字节吗？即使您有足够的内存和现代处理器，使该表扩大一倍可能会对参考位置产生不良影响，并且所有范围检查现在都是两步，降低了分支预测的有效性。而如果您没有那么多内存呢？
神话4：无符号算术是令人惊讶和不自然的。
这意味着有符号算术并不令人惊讶或者更自然。也许在数学方面思考时，所有基本算术运算都在所有整数集合上关闭。
但是我们的计算机不使用整数。它们使用整数的无穷小部分。我们的有符号算术不在所有整数集合上关闭。我们有溢出和下溢。对于许多人来说，这是如此令人惊讶和不自然，他们大多数时候都忽略了它。
这是一个错误：
auto mid = (min + max) / 2; // BUGGY
int作为文件大小一样。即使是C++17的文件系统API也不依赖于size_t用于文件大小；它使用uintmax_t。因此，这仍然不是size_t无符号的合理原因。 - Nicol Bolasvector或deque或其他任何东西；它总是一个明确设计为巨大的特定数据结构。因此，你将使用适合于容器预期大小的索引类型。 - Nicol Bolas