将size_t转换为长，有什么缺点吗?

不幸的是，"long"类型没有很好的理论基础。 最初，它是在 32 位 unix 端口上引入的，以区别于现有 PDP11 软件假设的 16 位"int"。 然后后来"int"在这些平台上被更改为32位（并引入了"短"），"long"和"int"成为同义词，它们在很长一段时间内都是如此。

现在，在64位类Unix平台上（Linux，BSD，OS X，iOS和人们可能仍然关心的任何专有Unix），"long"是64位的数量。 但是，可悲的是，不是在Windows上：现有标头中有太多遗留的"代码"，使得sizeof（int）==sizeof（long）假设，所以他们使用了一个名为"LLP64"的可憎的东西，并保留了32位。 叹息。

但"size_t"不是那样的。 它始终只意味着一件事：它是将本机指针大小存储在地址空间中的无符号类型。 如果你有一个无符号（！--如果需要有符号算术，请使用ssize_t或ptrdiff_t）指针，它需要整数表示（即你需要存储对象的内存大小），这就是你使用的。

现在这不是问题，但将来可能会有问题，具体取决于您将在何处移植应用程序。这是因为size_t被定义为足够大以存储指针的偏移量，因此如果您有 64 位指针，size_t也将是 64 位。现在，long 可能是也可能不是 64 位，因为 C/C++ 中基本类型的大小规则为某些变体提供了空间。

但是，如果要将这些值写入文件，则必须选择特定大小，因此除了转换为long（或long long，如果需要）之外别无选择。更好的是，使用一种新的特定于尺寸的类型，例如int32_t。

我的建议：在文件标题中的某个地方，存储将size_t转换为的类型的大小。通过这样做，如果您将来决定使用更大的尺寸，您仍然可以支持旧尺寸。对于该程序的当前版本，您可以检查大小是否受支持，如果没有，则发出错误。

将size_t转换为多头有什么缺点吗？

理论上长度可以小于size_t。此外，长是签名的。size_t未签名。因此，如果您开始在同一个表达式中同时使用它们，像 g++ 这样的编译器会抱怨它。好多。从理论上讲，由于已签名到未签名的分配，它可能会导致意外错误。

显然会有一些转换或添加多头

我不明白为什么应该有一些转换或增加长。您可以继续使用 size_t 进行所有算术运算。你可以把它类型化为"ListIndex"或其他什么，并在整个代码中继续使用它。如果你混合类型（长和size_t），g++/mignw会把你唠叨死。

或者，您可以选择具有保证大小的特定类型。较新的编译器具有 cstdint 标头，其中包括 uint64_t 等类型（例如，您极不可能遇到大于 2^64 的文件）。如果你的编译器没有标头，它应该在 boost 中可用。