我偶尔会在我的开源C ++库中使用64位算术。我发现long long非常适合我的目的。甚至一些10岁的solaris盒也可以编译它。它的工作原理也没有在Windows上使用#defines。
现在问题是我收到了用户的抱怨，因为他们使用GCC设置进行编译，并且GCC坚持发出long long不属于C ++标准的警告。这可能是正确的，但我对C ++标准本身并不太感兴趣，我只是希望我的代码尽可能多地使用编译器。
所以我的问题有两个：
long long）P.S。
如果有长平台变为128位或更大的平台，这很有趣，但对我来说不是问题。
答案 0 :(得分：16)
当您的库作为源提供时，一个选项是提供“移植”标头，用户有责任提供64位类型（您可以指定名称）。然后，他们自然也有责任处理任何类型选择引发的编译器警告，要么避开它们，要么禁止它们，要么忽略它们。
我想这就是你所谓的“乱搞#defines”，但我不认为它有太多错误。您可以提供一个直接使用long long的默认版本，它可以在您已有10年历史的Solaris盒子上运行，也可以在Windows上运行，因此大多数用户永远不需要靠近库中用户可配置的部分。
然后，对于迂腐的用户，您可以为GCC提供包含<sys/types.h>的版本，并使用int64_t代替long long。 g++ -pedantic对我没有任何警告。你甚至可以在默认版本中通过识别GCC来做到这一点，GCC肯定会搞乱#defines，但对于多平台产品来说再也不是这样了。
如果你的库也作为某些平台的二进制文件提供，那么当然你必须决定64位类型是什么。如果它也出现在库接口（以及头文件）中，那么您只需选择一个不会引发任何合理编译器选项警告的文件。我认为-pedantic是一个合理的编译器选项，显然你的用户也是如此，所以GCC再次int64_t。
答案 1 :(得分：12)
在GCC中使用-Wno-long-long编译器选项来禁止该特定警告。
您也可以使用-std=C++0x，但可能会进一步降低可移植性。
答案 2 :(得分：5)
您还可以使用gcc的“__extension__”功能来抑制警告，例如：
// No '-pedantic' warning/error.
__extension__ long long foo = 2;
// Exhibits '-pedantic' warning/error.
long long bar = 3
和编译：
$ g++ -pedantic -fsyntax-only foo.cpp
foo.cpp:5: error: ISO C++ 1998 does not support 'long long'
请注意，只有最后一次使用long long才会触发-pedantic错误，因为前面没有__extension__。无论如何，我会使用int64_t而不是{{1}}。
答案 3 :(得分：4)
您可以使用-Wno-long-long使警告静音（确保它在-pedantic之后）。 C99需要64位整数，我认为C ++ 0x也是如此，所以没有它们的编译器现在变得越来越少。
答案 4 :(得分：4)
如果您无法控制传递给gcc的开关，则可以使用#pragma关闭警告。
答案 5 :(得分：1)
如果你在系统包含目录中有Boost，你可以说
#include "boost/cstdint.hpp"
boost::int64_t my_64_bit_number;
如果它位于系统包含目录中，则会自动禁止警告。
答案 6 :(得分：0)
您可以将long long的使用替换为众多C ++ bigint库中的一个。我相信其中一些可以避免这种编译错误。就个人而言，我宁愿坚持这个错误。