问将size_t转换为long，有什么缺点吗？

EN

这现在不是问题，但可能会在未来，这取决于你的应用程序将移植到哪里。这是因为size_t被定义得足够大来存储指针的偏移量，所以如果你有一个64位的指针，size_t也将是64位的。现在，long可能是64位，也可能不是64位，因为C/C++中基本类型的大小规则为一些变化留出了空间。

但是，如果要将这些值写入文件，无论如何都必须选择一个特定的大小，因此除了转换为long (如果需要，也可以转换为long long )之外，别无选择。更好的是，使用一种新的特定于大小的类型，如int32_t。

我的建议是:在文件头的某个位置，存储您将size_t转换为的类型的大小。通过这样做，如果将来您决定使用更大的大小，您仍然可以支持旧的大小。对于当前版本的程序，您可以检查是否支持该大小，如果不支持，则发出错误。

不幸的是，"long“类型没有很好的理论基础。最初，它是在32位unix端口上引入的，目的是将它与现有PDP11软件假定的16位“整型”区分开来。后来，"int“在这些平台上被更改为32位(并引入了"short”)，" long“和"int”成为同义词，它们在很长一段时间内都是同义词。

现在，在64位的类unix平台上(Linux、BSD、OS、iOS以及人们可能仍然关心的任何专有的unix)，"long“是一个64位的数量。但是，不幸的是，不是在windows上:在现有的头文件中有太多的遗留“代码”，使得(整型)==sizeof(长)假设的大小，所以他们使用了一个叫"LLP64“的令人厌恶的东西，留下了32位的长度。叹一口气。

但是"size_t“不是这样的。它一直只意味着一件事:它是无符号类型，用于在地址空间中存储本机指针大小。如果你有一个需要整数表示形式的无符号(！--如果你需要有符号算术，使用ssize_t或ptrdiff_t )指针(即你需要存储一个对象的内存大小)，这就是你要使用的。

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

理论上，long可以比size_t小。而且，long是有符号的。size_t是未签名的。因此，如果你开始在同一个表达式中使用它们，像g++这样的编译器就会抱怨这个问题。很多。从理论上讲，由于签名到未签名的赋值，它可能会导致意外的错误。

显然会有一些long的转换或添加

我不明白为什么要对long进行一些转换或添加。你可以继续使用size_t进行所有的算术运算。您可以将其定义为"ListIndex“或其他任何形式，并在整个代码中继续使用它。如果你混合了类型(long和size_t)，g++/mignw会让你烦得要死。

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