要在可移植C ++库中使用的整数类型

Question

我维护一个应该在多个平台上运行的开源库，并提供（以及其他）本机数据类型的数学例程。我们希望尽可能提供64位计算。

我们的目标平台是32位和64位的Linux和OSX，Windows尚不支持，但大多数代码已知可以在Windows下运行，因此我们可以轻松地移植到Windows中。遥远的未来。因此，对于http://en.cppreference.com/w/cpp/language/types，我们对ILP32，LLP64和LP64感兴趣。 我们还与gmp（仅为int和long提供构造函数，但不为long long进行交互。）

我们现在遇到的问题归结为我们使用哪种原生整数类型作为我们的数字类型的默认值：

• 如果我们使用int，我们会在64位平台上回退到32位。
• 如果我们使用long，我们在Linux / OSX 64与Windows 64之间的行为会有不一致：Windows将无法使用64位计算。
• 如果我们使用long long，使用gmp会变得一团糟，因为从mpz_class创建long long会导致模糊的重载。我们必须预先将这些数字转换为长数（因此在许多地方仅在Windows上有效地使用32位。）
• 如果我们使用std::int64_t之类的，那么typedef在平台之间有所不同，因此我们会遇到同样的问题，每个平台只有不同的问题...

那是否有某种最佳做法？ 是否可以避免这些问题或者它们是C ++类型系统固有的？

当然，问题不会在这里结束。需要考虑的其他未决问题：

• 这些解决方案如何与std::size_t进行互动？ std::size_t有它的目的，但有时需要与我们计算的数字进行交互。显然，我们不想一直来回演绎。
• 我们如何处理其他数字类型的使用？如果我们提供函数f(T)并为T = int,long,long long提供重载但用户将其与std::int64_t一起使用，我们是否可以避免不同平台之间的不一致行为？ （具有std::int64_t的不同定义）如果我们还为std::int64_t提供重载，我们将有重复的重载。

PS：我已阅读c-long-long-int-vs-long-int-vs-int64-t和should-i-use-long-long-or-int64-t-for-portable-code。我对那里究竟发生了什么以及为什么会这样，但无法得出解决方案有了一些见解......

Answer 1

根据定义，您的Windows上的gmp永远不会支持64位值。因此，我建议您在代码中使用int64_t，并且只要您需要先将static_cast gmp与long进行交互，就可以随时使用RewriteLog "/tmp/debug.log" RewriteLogLevel 6 。