1. ホーム
  2. c#

C#でbyteやshortの代わりにintを使うべき理由

2023-08-11 12:42:28

疑問点

この問題に関して、いくつかのスレッドを見つけました。ほとんどの人は、モバイル アプリでない限り、byte または smallint がデータを処理する場合でも、c# コードで int を使用することを全面的に支持しているようです。私はその理由がわかりません。C#のデータ型をデータ ストレージ ソリューションと同じデータ型として定義する方がより理にかなっているのではないでしょうか?

私の前提 型付きデータセット、Linq2SQL クラス、POCO を使用している場合、階層間でデータ型を同期させないと、いずれにせよ、コンパイラーのデータ型変換の問題に直面することになります。私は、C#のコードで全面的にintを使うのが簡単だからといって、System.Convertを常に使用するのは好きではありません。私は常に、データベースとのインタフェースをクリーンに保つために、コード内だけでなく、データベースでデータを処理するために必要な最小のデータ型を使用してきました。ですから、私のC#コードの75%は、int型ではなくbyte型やshort型を使っていると思います。

可能性です。 これは、コード内のすべてのものに int を使用するほとんどの人は、SQL ストレージ データ型にも int データ型を使用し、データベースの全体的なサイズについては気にしない、あるいは、該当する場合はコード内で system.convert を行うということでしょうか?

私が気にする理由 私はずっと自分自身で仕事をしてきたので、ベスト プラクティスと標準的なコーディング規約に慣れ親しんでいたいのです。

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

パフォーマンス的には、ほとんどすべてのケースでint型が高速です。CPU は 32 ビットの値で効率的に動作するように設計されています。

より短い値を扱うのは複雑です。例えば1バイトを読むために、CPUはそれを含む32ビットブロックを読み、そして上位24ビットをマスクしなければなりません。

バイトを書き込むには、宛先の32ビットブロックを読み、下位8ビットを希望のバイト値で上書きし、再び32ビットブロック全体を書き戻す必要があります。

もちろん、スペース的には、より小さなデータ型を使用することで数バイトの節約になります。したがって、数百万行のテーブルを構築する場合、より短いデータ型を検討する価値があるかもしれません。(また、同じことが、データベースでより小さいデータ型を使用すべき良い理由かもしれません)。

また、正しさの面では、intは簡単にオーバーフローしません。もし、あなたが を考えると そして、将来のある時点で、コードに無害に見える変更が加えられて、より大きな値が格納されるようになったらどうでしょうか。

これらは、すべての積分データに対して int をデフォルトのデータ型として使用すべき理由の一部です。実際にマシン バイトを格納したい場合にのみ、byte を使用します。ファイル形式やプロトコルなど、実際に 16 ビットの整数値を指定するものを扱う場合のみ、shorts を使用します。一般的に整数を扱うのであれば、int 型にしてください。