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

Should I use long long or int64_t for portable code?

本文关键字：还是 long-long int64 可移植代码我应该更新时间：2023-10-16

我有一个用C和C++编写的开源代码库。我正在寻找一种保证至少为64位宽的整数类型，它可以在大多数操作系统X(英特尔，64位)和Linux上使用开源C和C++编译器进行可靠编译，而无需最终用户做太多额外工作。Windows和32位客户端支持目前并不重要。

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

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

我是否可以可靠地将int64_t强制转换为long long(类似地，转换为与uint64_t等效的unsigned)，以便将其与以long long为参数的现有函数和库一起使用？(当然还有回来。)

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

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

类型long long和unsigned long long是标准C和标准C++类型，每个类型至少有64位。据我所知，所有编译器都提供这些类型，除非可能处于-pedantic模式，但在这种情况下，int64_t或uint64_t也不适用于C++2011之前的编译器。在所有系统上，<stdint.h>也可用。也就是说，据我所知，你怎么拼写这个类型并不重要。<stdint.h>的主要目标是为特定数量的比特提供最佳匹配。如果您需要至少64位，但又想利用这种类型的快速实现，则可以使用<stdint.h>或<cstdint>中的int_least64_t或uint_least64_t(如果是后者，则名称在名称空间std中定义)。

当可移植性是一个重要目标时，是否建议使用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都很好。

使用int64_t。int64_t的意思是64位，无论你走到哪里，都会得到64位。long-long实际上和long一样依赖于实现。也就是说，long-long必须大于或等于long，但根据编译器和平台的不同，这可能会有所不同。