0
我維護一個開源庫，該庫應該在多個平臺上運行，並提供（除其他之外）本機數據類型的數學例程。我們希望儘可能提供64位計算。要在便攜式C++庫中使用的整型類型
我們的目標平臺是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會變得一團糟，因爲從long long創建mpz_class會導致模糊的過載。我們必須事先將這些數字轉換爲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。我得到了一些見解，究竟發生了什麼，爲什麼它是這樣的，但不能得出一個解決方案...
不知道問題是什麼。在任何符合實現的情況下，std :: int64_t是一個64位整數類型。'std :: size_t'不應該和你的數字有任何關係，這是一種表示對象大小的類型，沒有別的。最後但並非最不重要的是，如果任何嘗試可移植性的嘗試都不會使用「長」。這是**最波動的類型。我甚至知道在checkin類型中檢查'long'的環境，並且在你的代碼中有一個checkin塊。 – SergeyA
@SergeyA類型'intN_t'系列的問題是它們不一定存在。 – NathanOliver
@NathanOliver，OP提到OS X，Linux和Windows。它們確實存在於這些平臺上使用的主要C++實現上。 – SergeyA