固定サイズの整数（int64_t、int32_t）の代わりに非固定の整数（int、long）を使用する利点はありますか？

Question

多分パフォーマンスですか？固定されていない整数を使用すると、別のアーキテクチャに移植するときに、プログラムが複雑になり、失敗する傾向があるように感じます。

Answer 1

std::intN_tはonly if the implementation can directly support themを提供しています。したがって、それらを使用する移植コードは失敗する可能性があります。

制限が少なく、intと同じかそれ以上の速さでなければならないので、私は一般的にはstd::intfastN_tを好むでしょう。 intを受け入れる関数にstd::int32_tを渡すときあなたはsizeof(int)は16ビットのみである場合は特に、プロモーションおかしなに遭遇するかもしれないので

はまた、ほとんどのC++コードはどこにでもintを使用しています。

Answer 2

多くのAPIは、非固定型の値を受け入れたり返したりします。例えば、ファイル記述子がタイプint、ファイルオフセットやサイズであるタイプoff_tとstrtol()longを返すのです。このような値を固定サイズのタイプから盲目的に変換すると、一部のマシンでオーバーフローが発生する可能性があります。

Answer 3

保証幅タイプ（intN_t）は、単に適切な「標準」、整数タイプに型定義されています。プラットフォームが適切なタイプ（例えば、36ビットの整数を使用する）を持たない場合、保証されたタイプのtypedefを提供することはできません。 これは、パフォーマンスがほとんど引数になり得ないことを意味します。

（この点で）最大の移植のための一般的なガイドラインは、あなたのアルゴリズムは、ビットの正確な数を要求する場合にのみ、デフォルトで「標準」整数型と保証幅のタイプを使用することです。 標準の整数型は、関連する規格で保証されているものと同じ幅であることが前提です（8ビットのchar、16ビットのint、32ビットのlong、コンパイラがサポートしている場合は、64ビットのlong long）。

Answer 4

あなたがあなたのタイプのサイズは、それが機能だために重要であるデータを持っている場合は、あなたが定義したサイズと種類を使用する必要があります。しかし、例えば、あなたが合理的に期待できるint範囲（例えば、1〜1000ループカウンタ）内にあるコードの場合、int_32tを使用する理由はありません。それは16,32,64,36,18、または49ビットの整数ですべて正常に動作します。コンパイラに最適なサイズを選択させてください。

コンパイラがアーキテクチャにとって「最適な選択」ではない固定サイズの整数に対してコードを悪化させる可能性があります。

もちろん、ネットワーク上またはファイルに提示されているすべてのデータは、固定サイズを持っている必要があります。同様に、インタフェース境界を越えてバイナリ互換性が必要なインタフェースを持つ場合、定義されたサイズの型を使用することは、サイズが問題になるのを避けるために非常に便利です。