将size_t转换为long是否有任何缺点？因为，我正在编写一个在文件中维护linked_list的程序。所以我遍历基于size_t的另一个节点，我还跟踪列表总数为size_t。因此，很明显会有一些转换或添加long和size_t。这有什么不利之处吗？如果有，那么我会把所有东西都做为长而不是size_t，甚至是尺寸。请指教。
答案 0 :(得分：3)
遗憾的是，“长”型没有很好的理论依据。最初它是在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，如果你需要有符号算术）指针需要一个整数表示（即你需要存储一个对象的内存大小），这就是你使用的。
答案 1 :(得分：2)
将size_t转换为long是否有任何缺点？
理论上长度可以小于size_t。此外，长期签署。 size_t是无符号的。因此，如果你开始在同一个表达式中使用它们，像g ++这样的编译器会抱怨它。很多。从理论上讲，由于签名到无符号分配，它可能会导致意外错误。
显然会有一些转换或添加长
我不明白为什么会有一些转换或添加到long。您可以继续使用size_t进行所有算术运算。您可以将其定义为“ListIndex”或其他任何内容，并在整个代码中继续使用它。如果你混合使用类型（long和size_t），g ++ / mignw就会惹你生气。
或者，您可以选择具有保证大小的特定类型。较新的编译器具有cstdint标头，其中包含类似uint64_t的类型（例如，您遇到大于2 ^ 64的文件的可能性极小）。如果你的编译器没有头文件，它应该在boost中可用。
答案 2 :(得分：2)
现在不是问题，但可能会在将来取决于您移植应用的位置。这是因为size_t被定义为足以存储指针的偏移量，因此如果你有一个64位指针，size_t也将是64位。现在，long可能是64位，也可能不是64位，因为C / C ++中基本类型的大小规则为某些变化提供了空间。
但是如果您要将这些值写入文件，则必须选择特定大小，因此除了转换为long（或long long，如果需要）之外别无选择。更好的是，使用一种新的特定于大小的类型，如int32_t。
我的建议：在文件标题的某处，存储sizeoft转换类型的sizeof。通过这样做，如果将来你决定使用更大的一个，你仍然可以支持旧的大小。对于当前版本的程序，您可以检查是否支持大小，如果不支持则发出错误。