c++ - 如何在没有编译器警告的情况下进行可移植的 64 位算术

Question

我偶尔会在我的开源 C++ 库中使用 64 位算术。我发现 long long 非常适合我的目的。甚至一些有 10 年历史的 solaris 盒子也可以编译它。而且它也可以在 Windows 上使用 #defines，而不会乱七八糟。

现在的问题是我收到了用户的提示，因为他们使用 GCC -pedantic 设置进行编译，而 GCC 坚持发出警告说 long long 不是 C++ 标准的一部分。这可能是对的，但我对 C++ 标准本身并不太感兴趣，我只是希望我的代码能够在尽可能多的编译器上工作。

所以我的问题是双重的:

• 谁能说出不支持 64 位 long long 的实际 C++ 编译器？
• 有没有办法让 GCC 编译 64 位算术(在 32 位平台上)而没有编译器警告？ (stdint.h 没有帮助，因为它还依赖于 long long)

附:

如果有平台的 long long 变成 128 位或更大，那很有趣，但对我来说不是问题。

Answer 1

当您的库作为源提供时，一种选择是提供“移植” header ，您的用户有责任在其中提供 64 位类型(您需要指定名称)。然后，他们自然也有责任处理他们选择的类型引发的任何编译器警告，要么避免它们，要么抑制它们，要么忽略它们。

我猜这就是你所说的“搞乱#defines”，但我认为这并没有太大的问题。您可以提供仅使用 long long 的默认版本可以直接在您使用了 10 年的 Solaris 机器上运行，也可以在 Windows 上运行，因此大多数用户永远不需要靠近库的用户可配置部分。

那么对于学究气的用户，你可以提供一个包含<sys/types.h>的GCC版本。并使用 int64_t而不是 long long .这不会对我产生任何警告 g++ -pedantic .您甚至可以通过识别 GCC 在默认版本中执行此操作，这肯定会与#defines 混淆，但对于多平台产品来说，这又不是一种不寻常的方式。

如果您的库也作为特定平台的二进制文件提供，那么您当然必须确定 64 位类型将是什么。如果它也出现在库接口(interface)中(因此也出现在头文件中)，那么您只需选择一个不会通过合理的编译器选项引发任何警告的选项。我认为 -pedantic是一个合理的编译器选项，显然您的用户也是如此，所以这又是 int64_t在 GCC 上。