经典 C（Brian Kernighan 和 Dennis Ritchie 在 The C Programming Language，Prentice-Hall，1978 年描述的 C 的早期方言）没有提供 size_t。 C 标准委员会引入 size_t 以消除可移植性问题
Explained in detail at embedded.com (with a very good example)
简而言之，size_t 永远不会是负数，它最大限度地提高了性能，因为它的 typedef'd 是无符号整数类型，它足够大 - 但不是太大 - 可以表示目标平台上最大可能对象的大小。
大小永远不应该是负数，实际上 size_t 是一个无符号类型。此外，因为 size_t 是无符号的，您可以存储大约是相应有符号类型中的两倍大的数字，因为我们可以使用符号位来表示幅度，就像无符号整数中的所有其他位一样。当我们获得更多位时，我们将可以表示的数字范围乘以大约两倍。
那么，您问，为什么不直接使用 unsigned int？它可能无法容纳足够大的数字。在 unsigned int 为 32 位的实现中，它可以表示的最大数字是 4294967295。某些处理器（例如 IP16L32）可以复制大于 4294967295 字节的对象。
那么，您问，为什么不使用 unsigned long int？它会在某些平台上造成性能损失。标准 C 要求 long 至少占用 32 位。 IP16L32 平台将每个 32 位长实现为一对 16 位字。这些平台上的几乎所有 32 位运算符都需要两条指令，甚至更多，因为它们使用两个 16 位块中的 32 位。例如，移动一个 32 位的长度通常需要两条机器指令——一条用于移动每个 16 位的块。
使用 size_t 可以避免这种性能损失。根据 this fantastic article，“类型 size_t 是一个 typedef，它是一些无符号整数类型的别名，通常是 unsigned int 或 unsigned long，但甚至可能是 unsigned long long。每个标准 C 实现都应该选择无符号整数这足够大——但不会比需要的大——代表目标平台上最大可能对象的大小。”
unsigned int 中表示的最大值可以并且确实因系统而异。它必须是至少 65536，但通常是 4294967295，并且在某些系统上可能是 18446744073709551615 (2**64-1)。
unsigned char）。该标准似乎没有在任何地方包含字符串“65535”或“65536”，并且“+32767”仅出现在 (1.9:9) 的注释中，因为 可能 是 int 中可表示的最大整数；即使 INT_MAX 不能小于该值，也不能保证！
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 中的不同（它实际上指定了每个类型 'char'、'byte'、'short'、'int' 和 'long' 的位精度）。
size_t 能够表示任何单个对象的大小（例如：数字、数组、结构）。整个内存范围可能超过 size_t
size_t - 我希望你不是那个意思。大多数时候，我们不处理地址空间的基数+可移植性甚至很重要的数组。在这些情况下，您将使用 size_t。在所有其他情况下，您从（有符号）整数中取出索引。因为与其他情况下可能出现的可移植性问题相比，unsigneds 的未预料到的下溢行为引起的混淆（没有警告）更常见，也更糟糕。
size_t 应该用于所有非负数组索引。
index = x - y.. later: if (index < 0) -> fail, otherwise z = arr[index].. 如果在这里使用无符号整数会发生什么。顺便说一句，这也是 c++ 委员会对这个话题的官方立场
类型 size_t 必须足够大以存储任何可能对象的大小。 Unsigned int 不必满足该条件。
例如在 64 位系统中 int 和 unsigned int 可能是 32 位宽，但 size_t 必须足够大以存储大于 4G 的数字
size_t 只需要那么大。大多数编译器会拒绝，例如 typedef unsigned char foo[1000000000000LL][1000000000000LL]，即使 foo[65536][65536]; 超过了记录在案的实现定义的限制，也可能会被合理地拒绝。
在研究该主题时，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，将其定义为。大多数在 `sys/types.h' 中定义 size_t 的 Unix 系统将其定义为有符号类型。库中的一些代码依赖于 size_t 是一个无符号类型，如果它被签名将无法正常工作。
期望 size_t 为无符号的 GNU C 库代码是正确的。 size_t 作为有符号类型的定义是不正确的。我们计划在 2.4 版中，GCC 将始终将 size_t 定义为无符号类型，并且 fixincludes' script will massage the system'ssys/types.h' 不会与此冲突。
同时，我们通过明确告诉 GCC 在编译 GNU C 库时对 size_t 使用无符号类型来解决这个问题。 `configure' 将自动检测 GCC 用于 size_t 的类型，并在必要时安排覆盖它。
如果我的编译器设置为 32 位，则 size_t 只不过是 unsigned int 的 typedef。如果我的编译器设置为 64 位，则 size_t 只不过是 unsigned long long 的 typedef。
unsigned long。
size_t 是指针的大小。
所以在 32 位或常见的 ILP32（整数、长整数、指针）模型中 size_t 是 32 位。并且在 64 位或常见的 LP64（长指针）模型中 size_t 是 64 位（整数仍然是 32 位）。
还有其他模型，但这些是 g++ 使用的模型（至少默认情况下）
size_t 不一定与指针大小相同，但通常如此。指针必须能够指向内存中的任何位置； size_t 只需大到足以表示最大单个对象的大小。
intptr_t 的大小可能与 void * 指针相同。这不是必需的，但 intptr_t 必须能够保存 void * 指针的所有可能有效值。但size_t没有这个要求。另外 size_t 它至少为 16 位，而指针可以更小。
size_t可以表示的值的确切范围！如果没有，谁会？