我有一个用C和C ++编写的开源代码库。我正在寻找一个整数类型，该类型必须保证至少 64位宽，并且可以使用开源C和C ++编译器在大多数OS X（Intel，64位）和Linux机器上可靠地进行编译，而最终用户则不需要太多额外的工作。 Windows和32位客户端支持目前并不重要。
我在OS X上进行了一些测试，并且开发人员工具附带的最新GCC不支持C + 11模式（因此似乎不能保证long long的可用性）。 Clang也不支持此功能，尽管在特定版本之后，如果启用了C99模式，它也支持long long。
当便携性是重要目标时，是否一般建议使用int64_t代替long long？使用格式说明符似乎很痛苦。
我是否可以可靠地将int64_t强制转换为long long（并且同样强制转换为与unsigned等效的uint64_t），以将其与以long long作为参数的现有函数和库一起使用？ （然后再返回。）
在这种情况下，如果我在GCC中发布了需要Clang功能的代码，那么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位，但又想利用这种类型的快速实现，则可以使用int_least64_t或uint_least64_t中的<stdint.h>或<cstdint>（对于后者，名称在名称空间std中定义。
当便携性是一个重要目标时，是否一般建议使用
int64_t代替long long？
如果编译器提供int64_t但不提供long long，我会感到非常惊讶。
如果存在long long，则它必须至少具有64位，因此从(u)int64_t到(unsigned) long long的转换是保留值的。
如果需要类型为[[exactly 64位的类型，请使用(u)int64_t，如果需要至少 64位，则(unsigned) long long很好，就像(u)int_least64_t一样。