对于可移植代码，我应该使用 long long 还是 int64_t？

Question

我有一个用 C 和 C++ 编写的开源代码库。 我正在寻找一种保证至少64 位宽的整数类型，它可以在大多数 OS X（英特尔，64 位）和带有开源 C 和 C++ 编译器的 Linux 机器上可靠地编译，而无需太多最终用户方面的额外工作。 Windows 和 32 位客户端支持此时并不重要。

我在 OS X 上做了一些测试，开发者工具附带的最新 GCC 不支持 C+11 模式（因此似乎不能保证long long可用性）。 Clang 也不支持这个，尽管它在某个版本之后支持long long如果启用了 C99 模式。

当可移植性是一个重要目标时，一般建议使用int64_t代替long long吗？ 使用格式说明符似乎很痛苦。

我能否可靠地将int64_t为long long （同样转换为uint64_t的unsigned等效项）以将其与需要long long作为参数的现有函数和库一起使用？ （当然，然后再回来。）

在这种情况下，如果我发布的代码不需要 GCC 中的 Clang 功能，Clang 会取代 GCC 作为 Linux 上的首选编译器吗？ 在向最终用户提供源代码时，在大多数情况下，我可以期待那个编译器吗？

基本上，我想向其他使用这两种类型的可移植 C 和 C++ 代码的开发人员征求一些建议，考虑到上述目标，他们可能对什么可能是更好的长期发展方式有一些建议.

Answer 1

long long和unsigned long long类型是标准 C 和标准 C++ 类型，每个类型至少有 64 位。 我知道的所有编译器都提供这些类型，除非可能在-pedantic模式下，但在这种情况下int64_t或uint64_t也不适用于 pre-C++ 2011 编译器。 在所有系统上<stdint.h>也是可用的。 也就是说，据我所知，您如何拼写类型并不重要。 <stdint.h>的主要目标是为特定数量的位提供最佳匹配。 如果你需要至少64位，但你也想采取禁食实现这种类型的优势，你会使用int_least64_t或uint_least64_t从<stdint.h>或<cstdint>在后一种情况下，该名称是在命名空间std定义）。

Answer 2

当可移植性是一个重要目标时，一般建议使用int64_t代替long long吗？

如果编译器提供int64_t但不是long long我会感到非常惊讶。

如果long long存在，则它必须至少有 64 位，因此从(u)int64_t为(unsigned) long long是保值的。

如果您需要一个正好为64 位的类型，请使用(u)int64_t ，如果您需要至少64 位， (unsigned) long long非常好， (u)int_least64_t 。

Answer 3

使用 int64_t。 int64_t 表示 64 位，无论您走到哪里，都会得到 64 位。 long long 实际上与 long 一样依赖于实现。 也就是说，long long 必须大于或等于 long，但这可能因编译器和平台而异。