對於可移植代碼，我應該使用 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，但這可能因編譯器和平台而異。