我有一个用C和C ++编写的开源代码库。我正在寻找一个保证至少 64位宽的整数类型，可以在大多数OS X（Intel，64位）和带有开源C的Linux机箱上可靠地编译和C ++编译器，对最终用户没有太多额外的工作。 Windows和32位客户端支持目前并不重要。
我在OS X上做了一些测试，开发人员工具附带的最新GCC不支持C + 11模式（因此似乎不能保证long long的可用性）。 Clang也不支持这一点，但如果在某个版本之后启用了C99模式，它支持long long。
当便携性是一个重要目标时，一般建议使用int64_t代替long long吗？使用格式说明符似乎很痛苦。
我是否可以可靠地将int64_t转换为long long（同样地unsigned等同于uint64_t）以将其用于现有函数和库{{1}作为参数？ （当然，又回来了。）
在这种心态下，如果我发送的代码不需要在GCC中使用Clang功能，那么Clang是否会取代GCC作为Linux上的首选编译器？在为最终用户提供源代码时，大多数情况下，这个编译器是我可以期待的吗？
基本上，我想向其他开发人员提出一些建议，他们使用这两种类型的可移植C和C ++代码，他们可能会对可能是更好的长期方法提出一些建议，鉴于上述情况目标在于。
答案 0 :(得分：32)
类型long long和unsigned long long是标准C和标准C ++类型，每个类型至少有64位。我知道的所有编译器都提供这些类型，但可能在-pedantic模式下，但在这种情况下，{C} 2011编译器将无法使用int64_t或uint64_t 。在所有系统上<stdint.h>也可用。也就是说，据我所知，你拼写这个类型并不重要。 <stdint.h>的主要目标是为特定位数提供最佳匹配。如果您需要至少64位但又想要利用这种类型的禁食实现，则可以使用int_least64_t或uint_least64_t中的<stdint.h>或<cstdint> （如果是后者，名称在名称空间std中定义）。
答案 1 :(得分：25)
当可移植性是一个重要目标时，一般建议使用
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。
答案 2 :(得分：-1)
使用int64_t。 int64_t表示64位，无论您走到哪里，您都将获得64位。 long long实际上与long的实现相关。也就是说，long long必须大于或等于long，但这取决于编译器和平台。