“size_t”是否使代码可移植，或者只是“更”可移植？答案

【问题标题】：Does "size_t" make code portable, or just 'more' portable?“size_t”是否使代码可移植，或者只是“更”可移植？
【发布时间】：2017-03-11 23:15:51
【问题描述】：

我很难理解 C++ std::size_t 数据类型的用处。我意识到这种数据类型是平台相关的，据说是为了让代码更便携。但是，它似乎并没有解决所有问题。

例如，我正在使用具有 32 位 int 的机器。假设我决定编写这台机器的 c 风格函数，它只是将字节从一个对象复制到另一个对象。在该函数内部，memcpy 函数用于将数据从 object2 写入 object1。我选择了一个任意大的数字。

void writeBytes(obj *pobj1, obj *pobj2) 
{
    memcpy(pobj1, pobj2, 1048575);
}

这段代码应该（希望）编译得很好。因为 memcpy 在其声明中使用了 size_t，并且因为这个平台上的 size_t 应该是 32 位，所以 1048575 的数量应该可以正常工作。

但是现在假设我决定将这个函数移植到一台 16 位整数的机器上。现在 memcpy 函数将 size_t 解释为大小 16。在这种情况下，1048575 超出了 memcpy 声明的允许值。然后代码编译失败。

所以我的问题是： size_t 在这种情况下到底有什么用？它是如何让我们的代码更便携的？

【问题讨论】：

您确实意识到，不考虑源缓冲区和目标缓冲区的大小，您不能只复制任意数量的字节？
谁告诉你memcpy(pobj1, pobj2, 1048575); 可以正常工作？
更便携和更不便携就是一切。没有保证在任何地方都能以完全相同的方式工作的可移植性水平，至少对于任何有用的非平凡程序来说都不是。使您的代码“只是”更具可移植性的东西并没有错。
如果您在 16 位机器上工作，可寻址内存不超过 65536 字节。您将无法创建两个指针，每个指针都指向 1048575 的大小，更不用说使用 memcpy() 从一个复制到另一个了。如果您硬编码该长度，通常会出现编译错误，因为编译器可以识别出该值超出了 size_t 可以表示的值。
将较大的整数转换为size_t 不会出现编译错误。这是一个定义明确的操作（值以SIZE_MAX+1为模调整）。

标签： c++ c

【解决方案1】：

size_t 能够容纳您可以创建的最大对象的大小。它不需要是您平台最大的原生整数类型。

根据您的示例，无论原生整数是 16 位还是 32 位，您的代码都可以工作如果您的平台允许 1048575 字节对象。或者反过来——如果 1048575 不适合 size_t，你永远不可能创建一个比 memcpy 大的对象。

【讨论】：

【解决方案2】：

size_t 容易受到与任何其他整数类型相同的上溢和下溢规则的影响。它只是无符号整数的 typedef。它的目的不是阻止您分配或转换超出其范围的值。它定义了一个标准类型，它将：

"存储理论上可能的任意类型对象的最大尺寸（包括数组）。”

如果您关心最大尺寸，请使用

std::numeric_limits<std::size_t>::max()

并据此做出决定。

【讨论】：

【解决方案3】：

我认为size_t 使（不仅是您的）代码更具可读性和一致性，但不一定更便携。但是，它会帮助移植它。

想象一下使用某种大小的函数使用int、short、long、unsigned、unsigned short、...的快乐混合

当一个处理大小的函数调用另一个也需要大小参数的函数时，当一个size_t 适合所有情况（或至少大多数情况，例如read() 的结果）时，它会非常有用。

【讨论】：