使用非固定整數（int，long）代替固定大小的整數（int64_t，int32_t）有什么優勢嗎？

Question

也許表現？ 我覺得使用非固定整數只會使程序更加復雜，並且在移植到另一個體系結構時很容易失敗。

Answer 1

僅當實現可以直接支持 std::intN_t提供它們 。 因此，移植使用它們的代碼可能會失敗。

我更喜歡將std::intfastN_t用於一般用途，因為它們的限制較少，並且應與int一樣快或更快。

而且，大多數C ++代碼在任何地方都使用int ，因此，當將std::int32_t傳遞到接受int的函數中時，您可能會遇到升級怪異的現象，尤其是在sizeof(int)只有16位的情況下。

Answer 2

許多API接受或返回非固定類型的值。 例如，文件描述符的類型為int ，文件的偏移量或大小為off_t並且strtol()返回long 。 盲目地將這些值從固定大小類型轉換為固定大小類型，可能會導致某些機器溢出。

Answer 3

保證寬度類型（ intN_t ）只是適當的“標准”整數類型的typedef。 如果平台沒有適當的類型（例如，它使用36位整數），則它不能也不能提供保證寬度的typedef。 這意味着性能很難成為爭論的焦點。

關於最大可移植性的一般指導原則（就此而言）是默認情況下僅使用“標准”整數類型和保證寬度類型，前提是您的算法需要精確的位數。 應該假定“標准”整數類型的寬度只有相關標准所保證的寬度（如果僅查看C ++標准，則為：8位char ，16位int ，32位long以及如果您的編譯器支持，則為64位long long ）。

Answer 4

如果您的數據中類型的大小對其功能至關重要，則應使用定義大小的類型。 但是，例如一段代碼在[您可以合理預期的] int范圍之內（例如1 ... 1000循環計數器），就沒有理由僅僅因為您要定義變量而使用int_32t 。 使用16位，32位，64位，36位，18位或49位整數都可以正常工作。 因此，讓編譯器選擇最佳大小。

編譯器可能會為固定大小的整數生成較差的代碼，而固定大小的整數對於該體系結構不是“最佳選擇”。

顯然，通過網絡或文件中顯示的任何數據都必須具有固定大小。 同樣，如果您的接口需要跨接口邊界的二進制兼容性，那么使用定義的大小類型對於避免大小成為問題非常有用。