c++ - 将size_t转换成long，有什么缺点吗？

Question

将 size_t 转换为 long 有什么缺点吗？因为，我正在编写一个在文件中维护linked_list 的程序。因此，我根据 size_t 遍历到另一个节点，并且还将列表的总数跟踪为 size_t。因此，显然会有一些 long 和 size_t 的转换或添加。这有什么缺点吗？如果有，那么我会让所有东西都变长而不是 size_t，甚至是尺寸。请指教。

Answer 1

不幸的是，“长”类型没有良好的理论基础。最初它是在 32 位 unix 端口上引入的，以区别于现有 PDP11 软件假定的 16 位“int”。后来“int”在这些平台上更改为 32 位（并引入了“short”），“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）指针（即您需要存储对象的内存大小），这就是您使用的。

Answer 2

将 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.js 中可用。

Answer 3

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

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

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