4

私は、C++ でコード化されたゲーム サーバーを実行しており、そこには ASM と C も少し含まれています。誰かが私が実行している同じサーバーを更新したのを見ました。すべての更新の中で、すべての int、unsigned、short、およびその他すべてが int32_t、uint32_t、uint64_t などに変更されたという事実がありました。

それらをすべて上記のものに変更することに利点はありますか？すべての int を int32_t に変更し、すべての unsigned int を uint32_t に変更したとしましょう。もちろん、その他すべての変更が可能です。

何か利点があるかどうかを読んで理解しようとしていましたが、それらの本当の意味を理解していませんでした. ええ、質問は次のとおりです。私が言ったことを行うことには何か利点がありますか?

私が使用するコンパイラは Orwell Dev-C++ です

4

4 に答える 4

2

uint32_t固定サイズと符号を使用して、データ型の処理をint32_tもう少し制御します。プログラムの予測可能性が高いほど、それは優れています。また、タイプ名で、署名されていないかどうかを確認できます。これは、常に自明であるとは限りません

適切に定義されたサイズにより、移植可能なコードを実行するときにもより保護されます。

于 2013-10-16T10:15:44.597 に答える
1

実際、デフォルトの int と long は非常にあいまいで、コンパイラ/プラットフォームに依存するため、私はそれらを避けようとしています。int と long の場合:

  • 構造体のサイズを知る必要がある場合は、アーキテクチャごと、オペレーティング システムごと、コンパイラごとに、int と long のバイト数を知る必要があります。貴重な頭脳の無駄遣いです。
  • そのハッシュ テーブルで衝突が発生する可能性を誰かに説明する必要がある場合、「それは int のサイズに依存します。これはアーキテクチャに依存します」と言うでしょうか、それとも 1.0e-5 と言うでしょうか? つまり、int と long は、プログラムのプロパティを「未定義」にします。
  • int を使用し、コンパイラがそれが 64 ビットであると断言した場合、それを 32 または 16 に最適化する可能性は最小限です。したがって、短い記号を表すためのスペースだけが必要な場合は、より多くのメモリを使用することになります... 2 ^ 32文字の多くのアルファベットを知っているわけではありません。

uint32_t や uint_least32_t などのより有益な型を使用すると、コンパイラはより適切な想定を行い、64 ビットを使用することでパフォーマンスが向上すると判断できる場合があります。私は確かにそれを知りません。しかし、人間として、プログラムがうまく機能する値の範囲を理解する可能性は高くなります。

さらに、すべてのバイナリ プロトコルは、整数のサイズとエンディアンを指定する必要がある可能性があります。

于 2013-10-16T13:43:57.683 に答える