反对使用size_t有什么争论？

Question

我有这样的API，

class IoType {
......
    StatusType writeBytes(......, size_t& bytesWritten);
    StatusType writeObjects(......, size_t& objsWritten);
};

我尊重的团队的高级成员似乎有类型size_t的问题，并建议我使用C99类型。我知道这听起来很愚蠢，但我一直认为像uint32_t和uint64_t这样的c99类型看起来很难看。我确实使用它们，但只有当它真的有必要时，例如当我需要序列化/反序列化一个结构时，我确实想要具体说明我的数据成员的大小。

反对使用size_t有什么争论？我知道这不是一个真正的类型，但如果我确定即使一个32位整数对我来说已经足够了，并且大小类型似乎适合于字节数或对象数量等。

Answer 1

在处理任何类型的序列化（二进制文件，网络等）时，使用精确大小的类型，如uint32_t。每当您处理内存中对象的大小时，请使用size_t - 这就是它的目的。所有处理对象大小的函数，例如malloc，strlen和sizeof运算符都为size_t。

如果正确使用size_t，您的程序将具有最大的可移植性，并且不会在不需要的平台上浪费时间和内存。在32位平台上，size_t将为32位 - 如果您使用uint64_t，则会浪费时间和空间。相反，在64位平台上，size_t将为64位 - 如果您使用uint32_t，您的程序可能会出现错误（甚至崩溃或打开安全漏洞），如果有的话处理大于4 GB的内存。

Answer 2

嗯，用不太便携的C99固定尺寸或最小尺寸的无符号类型替换size_t（最便携的东西）不是一个好主意。

另一方面，您可以使用签名的ptrdiff_t类型来避免许多技术问题（浪费时间）。标准库使用无符号类型仅仅是出于历史原因。它在当时是有道理的，甚至在今天的16位架构上都是有道理的，但通常它只是麻烦和麻烦。详细程度。

进行此更改需要一些支持，特别是 a general size function ，它会将数组或容器大小作为ptrdiff_t返回。

<小时/> 现在，关于你的功能签名

    StatusType writeBytes(......, size_t& bytesWritten);

这个强制调用代码对字节写入计数的类型选择。

然后，强制使用无符号类型size_t，很容易引入错误，例如通过检查是否小于或大于某个计算数量。

一个奇怪的例子：std::string("ah").length() < -5保证true。

相反，那就是......

    Size writeBytes(......);

或者，如果您不想使用例外，

    Size writeBytes(......, StatusType& status );

可以将可能的状态枚举为无符号类型或其他类型，因为对状态值的唯一操作是等式检查，可能是键。

Answer 3

在您不需要序列化值的上下文中使用size_t时，我想不出有什么问题。正确使用size_t将增加代码在32位和64位模式中的安全性/可移植性。