[解決済み] なぜuint_fast32_tではなく、uint32_tが好まれるのですか？

疑問点

どうやら uint32_t よりもはるかに一般的です。 uint_fast32_t (の方がはるかに多い（これは逸話的な証拠であることは承知しています）。私には直感に反しているように見えますが。

私が実装を見たとき、ほとんどいつも uint32_t を使用する実装を見ると、本当に欲しいのは 4,294,967,295 までの値を保持できる整数です (通常は 65,535 と 4,294,967,295 の間のかなり低い境界です)。

を使用するのは奇妙に思えます。 uint32_t のように 'ちょうど 32 ビット' の保証は不要であり '最速で利用可能な >= 32 ビット' の保証は不要です。 uint_fast32_t は、まさに正しい考えであるように思えます。さらに は通常実装されていますが uint32_t は実際に存在することが保証されていません。

では、なぜ uint32_t が好まれるのでしょうか？単によく知られているだけなのか、それとも他に技術的な利点があるのでしょうか？

どのように解決するのですか？

uint32_t は、それをサポートするどのプラットフォームでも、ほぼ同じプロパティを持つことが保証されています。 ¹

uint_fast32_t は、比較のために異なるシステムでどのように動作するかについて、ほとんど保証がありません。

が動作するプラットフォームに切り替えた場合 uint_fast32_t が異なるサイズであるプラットホームに切り替えた場合、すべてのコードで uint_fast32_t を使用するすべてのコードを再テストし、検証する必要があります。 すべての安定性の前提が崩れることになります。 システム全体が異なる動作をすることになります。

コードを書くとき、あなたはもしかしたら アクセス にアクセスできないかもしれません。 uint_fast32_t システムにアクセスすることができます。

uint32_t は異なる動作をしません（脚注を参照）。

正しさはスピードよりも重要です。 したがって、早すぎる最適化よりも早すぎる正しさの方が良い計画です。

というシステムのためにコードを書いていた場合、私は uint_fast32_t が 64 ビット以上のシステム用にコードを書いている場合、両方のケースについて自分のコードをテストしてそれを使用することがあります。 必要性と機会の両方がない限り、そうすることは悪い計画です。

最後に uint_fast32_t よりも遅くなることがあります。 uint32 は、キャッシュ サイズとメモリ帯域幅の問題により、よりも遅くなることがあります。 今日のコンピュータは、CPU よりもメモリに縛られることがはるかに多く、また uint_fast32_t は単独ではより高速ですが、メモリのオーバーヘッドを考慮するとそうではありません。

¹ コメントで @chux さんが指摘しているように、もし unsigned よりも大きい場合 uint32_t の演算は uint32_t は通常の整数演算を行い、そうでない場合は uint32_t . これはバグの原因になります。 完璧なものはないのです。