APIドキュメントによると
BigInteger は操作の結果を収容するために必要な大きさになるため、オーバーフローに関する Spec の詳細はすべて無視されます。
これは、十分なメモリが利用可能であると仮定して、BigInteger がオーバーフローしないことを意味しますか? もしそうなら、なぜ一部の「型」をオーバーフローさせ、一部をオーバーフローさせないのでしょうか?
言語が進化するにつれて、オーバーフローするメカニズムをプログラマーから隠す型が好まれるでしょうか?
APIドキュメントによると
BigInteger は操作の結果を収容するために必要な大きさになるため、オーバーフローに関する Spec の詳細はすべて無視されます。
これは、十分なメモリが利用可能であると仮定して、BigInteger がオーバーフローしないことを意味しますか? もしそうなら、なぜ一部の「型」をオーバーフローさせ、一部をオーバーフローさせないのでしょうか?
言語が進化するにつれて、オーバーフローするメカニズムをプログラマーから隠す型が好まれるでしょうか?
BigInteger を処理するのに十分なメモリがあると仮定すると、オーバーフローすることはありません。
一部の型をオーバーフローさせ、他の型をオーバーフローさせない理由についての質問に答えるには、次のようにします。
BigInteger は実際には型ではありません。クラスです。これは、int と同じ機能を提供するように設計されたラッパー クラスですが、オーバーフローを心配することなく、必要なだけ大きな数値を使用できます。
型は単に数バイト (正確な量は型によって異なります) のメモリであるため、オーバーフローが発生します。その少量のメモリがオーバーフローすると、数値もオーバーフローします。
特にそうするように設計されていない限り (またはリソースが不足している場合)、クラスが「オーバーフロー」することはありません。クラスは、含まれるすべてのものに対して十分なメモリを使用して定義されます。ほとんどの場合、他のクラスまたは他のデータ構造への参照になります。
あなたはそれを正しく読んでいます、それは決してオーバーフローしません。ただし、それによって RAM がさらに作成されるわけではありません :)
算術演算のセマンティクスは、Java 言語仕様で定義されているように、Java の整数算術演算子のセマンティクスを正確に模倣しています。たとえば、ゼロによる除算は ArithmeticException をスローし、負の値を正の値で除算すると、負 (またはゼロ) の剰余が生成されます。BigInteger は操作の結果を収容するために必要な大きさになるため、オーバーフローに関する Spec の詳細はすべて無視されます。
もしそうなら、なぜ一部の「型」をオーバーフローさせ、一部をオーバーフローさせないのでしょうか?
それは完全にそれがどのように支えられているかにかかっています。たとえば、プレーンなバニラのプリミティブint
に支えられている場合、明らかに でオーバーフローしInteger.MAX_VALUE
ます。プリミティブには明確なオーバーフロー境界がありますが、オブジェクトの境界は、それらがどのようにバックアップ/プログラムされているかによって異なります。
BigInteger は決してオーバーフローしません! これは任意のサイズであるため、メモリ (および Java ヒープ) が収容できる最大数に対応できます。
正解です。BigInteger はオーバーフローしません。ソフトウェア操作と動的割り当てを使用して、任意のサイズの数値を格納します。
コンピューティングのすべてのものと同様に、「任意のサイズ」は、「基盤となるシステムのリソースがなくなるまで」という別の言い方です。