java - JavaのFileInputStream readメソッドがshortではなくintを返すのはなぜですか?

Question

byte は read メソッドの結果を格納するのに十分な適切な型ではないことを認識しています。
したがって、read メソッドは int 型の値を返します。
しかし、int型よりもshort型の方が効率的な型だと思います。
-256 ~ 255 の範囲の値が含まれる可能性があります。
read メソッドが short ではなく int を返すのはなぜですか?

Answer 1

いくつかの理由があります:

• 32 KB を超えるデータを簡単に読み取ることができますが、shortこのタイプではオーバーフローが発生します
• プロセッサの「ビット数」により、 のパフォーマンスは のパフォーマンスとshort同等です。int最新の CPU は 32 ビットまたは 64 ビットの数値を取り、両方に適合intしshortます。古い 16 ビット プロセッサでコードを実行すると、パフォーマンスが向上しました。昔...

Answer 2

ファイルから読み取られたバイト数を示すRead メソッドの戻りint値は、API の作成中に行われた設計上の決定であり、同じ質問を別の方法で行うことができます。

読み取ることができる最大バイト数は?

•short: short データ型は、16 ビットの符号付き 2 の補数整数です。最小値は -32,768 で、最大値は 32,767 (両端を含む) です。メモリの節約が実際に重要な状況では、ショートを使用して大きな配列でメモリを節約できます。

•int: デフォルトでは、int データ型は 32 ビットの符号付き 2 の補数整数で、最小値は -231、最大値は 231-1 です。

バイトを保持するのに十分なメモリがあると仮定すると、int は short よりも優れた候補となるため、API 設計に役立ちます。ただし、API は、使用可能なリソースに基づいて読み取るバイト数を決定する決定をユーザーに任せます。

また、readメソッドはネイティブ コードを呼び出し、ネイティブ言語側では、これらのプリミティブ データ型が最も近いネイティブ言語データ型にマップされます。

乾杯 ！！

Answer 3

本当の理由は、FileInputStream が継承する抽象クラスは、任意のエンコーディングで文字を読み取ることになっている InputStreams のベースでもあり、メソッドを持っているためです。

public int read();

これは、文字読み取りストリームで 1 文字を読み取るために使用されます。

ご存知のように、charは 16 ビットの符号なし整数型です。

したがって、shortは 32k (または 15 ビット相当) の正の値しかないため使用できませんが、文字には 64k (または 16 ビット相当) が必要です。

そして、ファイルの終わりを知らせるために (-1) が必要です。

Readerそれはあらゆる種類の sと同じ話です。

Answer 4

これは、read が読み取ったバイト数を返すためです。InputStream には次のメソッドが定義されています。

public int read(byte[] b) throws IOException

入力ストリームからいくつかのバイトを読み取り、それらをバッファ配列 b に格納します。実際に読み取られたバイト数は整数として返されます。このメソッドは、入力データが使用可能になるか、ファイルの終わりが検出されるか、例外がスローされるまでブロックされます。

配列の最大長は約 Integer.MAX - 5 です。配列を操作できるため、戻り値の型は int になります。