Javaがunsigned intをサポートしないのはなぜですか？

Javaに符号なし整数のサポートが含まれていないのはなぜですか？

予想外に大きな入力でオーバーフローが発生する可能性が低いコードを記述できることを考えると、私には奇妙な省略のようです。

さらに、符号なし整数を使用すると、unsigned intが保持することを意図していた値が負になることは決してないことが示されているため、自己文書化の一種になる可能性があります。

最後に、場合によっては、除算などの特定の演算では符号なし整数の方が効率的です。

これらを含めることの欠点は何ですか？

これは、シンプルさについてのGoslingなどへのインタビューからのものです。

ゴスリング：私が言語デザイナーとして、私は最近自分自身を数えていませんが、「シンプル」が本当に意味を持っていたのは、J。ランダム開発者が仕様を頭に抱くと期待できたからです。その定義によれば、たとえば、Javaはそうではありません。実際、これらの言語の多くは、誰もが実際に理解していない、多くのコーナーケースに陥っています。符号なしのC開発者をクイズすると、すぐに、ほとんどのC開発者が実際に符号なしで何が行われるか、符号なし算術が何であるかを理解していないことがわかります。そのようなことがCを複雑にしました。Javaの言語部分は、かなり単純だと思います。検索する必要があるライブラリ。

行間を読むと、ロジックは次のようなものだったと思います。

• 一般に、Java設計者は、利用可能なデータ型のレパートリーを簡素化したいと考えていました
• 日常的には、最も一般的なニーズは署名されたデータ型であると感じていました
• 特定のアルゴリズムを実装するために、符号なし算術が必要になる場合がありますが、そのようなアルゴリズムを実装するプログラマの種類には、符号付きデータ型を使用して符号なし算術を「回避」する知識もあります。

ほとんどの場合、それは合理的な決定でした。おそらく、私は持っているでしょう：

• この1つのデータ型に対して、バイトを符号なしにするか、少なくとも名前が異なる可能性のある、署名済み/署名なしの代替を提供しました（署名することで一貫性が向上しますが、いつ符号付きバイトが必要になるのでしょうか？）
• 'short'を廃止（最後に16ビット符号付き算術を使用したのはいつですか？）

それでも、多少の手間がかかりますが、32ビットまでの符号なし値の演算は悪くありません。ほとんどの人は、符号なし64ビット除算や比較を必要としません。

これは古い質問で、パットはcharについて簡単に言及しましたが、これを今後検討する他の人のために、これについてさらに詳しく説明する必要があると思いました。Javaプリミティブ型をさらに詳しく見てみましょう。

byte -8ビット符号付き整数

short -16ビット符号付き整数

int -32ビット符号付き整数

long -64ビット符号付き整数

char -16ビット文字（符号なし整数）

算術charはサポートしていませんがunsigned、基本的にはunsigned整数として扱うことができます。算術演算を明示的ににキャストし直すchar必要がありますが、unsigned数値を指定する方法を提供します。

char a = 0;
char b = 6;
a += 1;
a = (char) (a * b);
a = (char) (a + b);
a = (char) (a - 16);
b = (char) (b % 3);
b = (char) (b / a);
//a = -1; // Generates complier error, must be cast to char
System.out.println(a); // Prints ? 
System.out.println((int) a); // Prints 65532
System.out.println((short) a); // Prints -4
short c = -4;
System.out.println((int) c); // Prints -4, notice the difference with char
a *= 2;
a -= 6;
a /= 3;
a %= 7;
a++;
a--;

はい、符号なし整数の直接サポートはありません（明らかに、直接サポートがあったとしても、ほとんどの操作をcharにキャストし直す必要はありません）。ただし、符号なしのプリミティブデータ型は確かに存在します。符号なしバイトも見たかったのですが、メモリコストを2倍にして、代わりにcharを使用することは実行可能なオプションだと思います。

編集する

JDK8には、新しいAPIがLongあり、値を符号なしの値としてInteger扱うときにヘルパーメソッドを提供します。longint

• compareUnsigned
• divideUnsigned
• parseUnsignedInt
• parseUnsignedLong
• remainderUnsigned
• toUnsignedLong
• toUnsignedString

さらに、Guavaは整数型に対して同様のことを行うための多数のヘルパーメソッドを提供します。これは、整数に対するネイティブサポートの欠如によって残されたギャップを埋めるのに役立ちunsignedます。

Javaには符号なしの型があり、少なくとも1つはあります。charは符号なしのshortです。したがって、Goslingがスローするどのような言い訳でも、他の符号なしの型がない理由は、実際には彼の無知にすぎません。

また、ショートタイプ：ショートパンツはマルチメディアで常に使用されます。その理由は、単一の32ビット符号なしlongに2つのサンプルを収め、多くの演算をベクトル化できるためです。8ビットデータと符号なしバイトについても同様です。ベクトル化のために、4つまたは8つのサンプルをレジスターに収めることができます。

符号付きの整数と符号なしの整数が式に混在するとすぐに、事態は乱雑になり始め、おそらく情報を失うことになります。Javaを署名されたintに制限すると、本当に問題が解決するだけです。署名付き/署名なしのビジネス全体について心配する必要がないのは嬉しいですが、バイトの8番目のビットを見落とすこともあります。

http://skeletoncoder.blogspot.com/2006/09/java-tutorials-why-no-unsigned.html

この男は、C標準がunsignedおよびsigned intを含む操作をunsignedとして処理するように定義しているためと述べています。これにより、負の符号付き整数が大きなunsigned intに転がり、バグが発生する可能性があります。

Javaはそのままでも問題ないと思いますが、署名なしを追加すると、あまり利益がなくても複雑になります。単純化された整数モデルを使用しても、ほとんどのJavaプログラマーは基本的な数値型がどのように動作するかを知りません。Javaパズルの本を読んで、どのような誤解があるかを確認してください。

実用的なアドバイスについては：

• 値がやや任意のサイズで、に収まらない場合はint、を使用してくださいlong。それらがlong使用に適合しない場合BigInteger。

• スペースを節約する必要がある場合は、配列にのみ小さいタイプを使用してください。

• 正確に64/32/16/8ビットが必要な場合は、long/ int/ short/ byteを使用し、除算、比較、右シフト、およびキャストを除いて、符号ビットの心配をやめます。

「CからJavaへの乱数ジェネレーターの移植」に関するこの回答も参照してください。

JDK8それは彼らのためにいくつかのサポートを持っています。

Goslingの懸念にもかかわらず、Javaでは未署名の型が完全にサポートされる可能性があります。

私はこの投稿が古すぎることを知っています。ただし、Java 8以降では、intデータ型を使用して符号なし32ビット整数を表すことができます。これは、最小値が0、最大値が2 ³² -1です。使用Integer用途にクラスint符号なし整数などの静的メソッドのようなデータ型をcompareUnsigned()、divideUnsigned()等に追加されたInteger符号なし整数の算術演算をサポートするクラス。

最初のJavaリリースのすぐ近くに含まれるという話を聞いたことがあります。オークはJavaの前身であり、一部の仕様書では、悪意のある値について言及されていました。残念ながら、これらは決してJava言語にはなりませんでした。おそらく時間の制約が原因で、実装されなかったことが誰かにわかった限りです。

（1）符号なし整数を使用するほとんどのプログラムは符号付き整数と同じように使用でき、これは（2）符号なし整数を使用すると、作成が非常に簡単になりますが、整数演算のオーバーフローや、符号付きと符号なしの型間の変換時に重要なビットが失われるなどのデバッグが困難になります。符号付き整数を使用して誤って0から1を減算すると、多くの場合、プログラムがクラッシュし、2 ^ 32-1に回り込むよりもバグを見つけやすくなります。コンパイラと静的分析ツール、およびランタイムチェックでは、符号なし演算を使用することを選択したので、何をしているのかを知っていると仮定します。また、

ずっと前に、メモリが限られていて、プロセッサが64ビットで一度に自動的に動作しなかったとき、すべてのビットがより多くを数えるので、実際に署名されたバイトと署名されていないバイトまたはショーツのほうがはるかに重要であり、明らかに正しい設計決定でした。今日、ほとんどすべての通常のプログラミングの場合、signed intを使用するだけで十分です。プログラムで実際に2 ^ 31-1より大きい値を使用する必要がある場合は、とにかく長い時間が必要です。longを使用する領域に入ると、2 ^ 63-1の正の整数で本当に満足できない理由を考え出すのはさらに難しくなります。128ビットプロセッサに移行すると、問題はさらに少なくなります。

あなたの質問は「なぜJavaはunsigned intをサポートしないのか」ということです。

そしてあなたの質問への私の答えは、Javaがそのプリミティブ型のすべてを望んでいるということです：byte、char、short、int、およびlongは、アセンブリとまったく同じように、それぞれ、byte、word、dword、およびqwordとして扱われるべきであり、Java演算子は署名されていますそれのすべての操作が以外のプリミティブ型だ文字を、だけで文字彼らは、16ビットの符号なしのみです。

そう静的メソッドがあると仮定し、符号なしの動作も、32ビットおよび64ビットのため。

署名されていない操作のために静的メソッドを呼び出すことができる最終クラスが必要です。

この最終クラスを作成し、好きな名前を付けて、静的メソッドを実装できます。

静的メソッドの実装方法がわからない場合は、このリンクが役立つ場合があります。

私の意見では、JavaはC ++ にまったく似ていません。Javaが符号なしの型も演算子のオーバーロードもサポートしていない場合、JavaはC ++とCの両方から完全に異なる言語として扱う必要があると思います。

ちなみに言語名も全然違います。

したがって、JavaでCと同様のコードを入力することはお勧めしません。また、C ++と同様のコードを入力することもお勧めしません。Javaでは、次にC ++で実行したいことを実行できないためです。つまり、コードはC ++のようにまったく機能しなくなり、私にとっては、途中でスタイルを変更するために、そのようなコードを作成することはできません。

署名付きの操作にも静的メソッドを作成して使用することをお勧めします。コードで署名付きの操作のみが必要で、それが演算子のみを使用してください。

また、short、int、およびlongプリミティブ型の使用を避け、代わりにword、dword、およびqwordをそれぞれ使用することをお勧めします。演算子を使用する代わりに、符号なし演算および/または符号付き演算の静的メソッドを呼び出します。

符号付き操作のみを行い、コード内でのみ演算子を使用する場合は、これらのプリミティブ型short、int、およびlongを使用しても問題ありません。

実際にはword、dword、qwordは言語には存在しませんが、それぞれに対して新しいクラスを作成でき、それぞれの実装は非常に簡単です。

クラスwordはプリミティブ型shortのみを保持し、クラスdwordはプリミティブ型intのみを保持し、クラスqwordはプリミティブ型longのみを保持します。これで、すべての符号なしメソッドと符号付きメソッドを静的または非選択として、各クラスに実装できます。つまり、ワードクラスに意味のある名前を付けることにより、符号なしと符号付きのすべての16ビット演算、符号なしと符号付きの両方の32ビット演算すべて上の意味の名前を与えることによって署名DWORDクラスと符号なしと上の名前の意味を与えることにより、署名の両方のすべての64ビット演算QWORDクラスを。

あなたは、各メソッドのためにあまりにも多くの異なる名前を与えて気に入らない場合は、常にJavaがなかったことを読み取ることが、Javaでのオーバーロードの良いを使用することができない、あまりにもそれを取り除きます！

8ビットの符号付き演算の演算子ではなくメソッド、および演算子がまったくない8ビットの符号なし演算のメソッドが必要な場合は、Byteクラスを作成できます（最初の文字「B」が大文字であるため、これはプリミティブ型byte）とこのクラスのメソッドを実装します。

値渡しと参照渡しについて：

私が間違っていない場合、C＃のように、プリミティブオブジェクトは値によって自然に渡されますが、クラスオブジェクトは自然に参照によって渡されるため、タイプByte、word、dword、およびqwordのオブジェクトは、値ではなく参照によって渡されますデフォルトでは。JavaにC＃のように構造体オブジェクトがあったらいいので、すべてのByte、word、dword、qwordを実装して、クラスの代わりに構造体にすることができますなので、デフォルトでは、プリミティブ型のようなC＃の構造体オブジェクトのように、デフォルトでは参照ではなく値で渡されましたが、デフォルトでは参照ではなく値で渡されますが、そのJavaはC＃よりも悪いため、それを処理するために、デフォルトでは値ではなく参照によって渡されるクラスとインターフェースのみがあります。したがって、JavaやC＃の他のクラスオブジェクトと同様に、参照ではなく値でByte、word、dword、およびqwordオブジェクトを渡す場合は、コピーコンストラクターを使用するだけでよいのです。

それが私が考えられる唯一の解決策です。基本型をword、dword、qwordにtypedefできればいいのですが、Javaはtypedefもまったく使用しません。Cのtypedefに相当するusingをサポートするC＃とは異なります。

出力について：

同じビットシーケンスの場合、さまざまな方法でそれらを印刷できます。2進数、10進数（C printfでの％uの意味など）、8進数（C printfでの％oの意味など）、16進数（などC printfでの％xの意味）および整数として（C printfでの％dの意味と同様）。

Cのprintfは関数にパラメーターとして渡される変数の型を認識しないため、関数の最初のパラメーターに渡されるchar *オブジェクトからのみ、printfは各変数の型を認識します。

したがって、Byte、word、dword、およびqwordの各クラスでは、クラスのプリミティブ型が署名されていても、printメソッドを実装してprintfの機能を取得できます。数字を出力に出力するための論理演算とシフト演算。

残念ながら、私があなたに与えたリンクはこれらの印刷方法を実装する方法を示していませんが、これらの印刷方法を実装するために必要なアルゴリズムをググることができると私は確信しています。

それが私があなたの質問に答えてあなたに提案できるすべてです。

ので、unsignedタイプが純粋な悪です。

Cでunsigned - int生成するという事実unsignedはさらに悪です。

以下は、私を何度も焼いた問題のスナップショットです。

// We have odd positive number of rays, 
// consecutive ones at angle delta from each other.
assert( rays.size() > 0 && rays.size() % 2 == 1 );

// Get a set of ray at delta angle between them.
for( size_t n = 0; n < rays.size(); ++n )
{
    // Compute the angle between nth ray and the middle one.
    // The index of the middle one is (rays.size() - 1) / 2,
    // the rays are evenly spaced at angle delta, therefore
    // the magnitude of the angle between nth ray and the 
    // middle one is: 
    double angle = delta * fabs( n - (rays.size() - 1) / 2 ); 

    // Do something else ...
}

バグに気づきましたか？私は、デバッガーを使用してステップインした後でのみ、それを確認しました。

そのためn、符号なし型であるsize_t全体の表現n - (rays.size() - 1) / 2として評価しますunsigned。その式は、真ん中の1番目の光線の符号付き位置になることを意図しています。n左側の真ん中の1番目の光線は位置-1になり、右側の1番目の光線は位置+1になります。 abs値を取り、delta角度を掛けるnと、光線と中央の光線の間の角度が得られます。

残念ながら、上記の式には符号なしの悪が含まれており、たとえば-1と評価する代わりに、2 ^ 32-1と評価されていました。doubleバグを封印するためのその後の変換。

unsigned算術演算の誤用によって引き起こされた1 つか2つのバグの後、1つ追加のビットが追加のトラブルに値するかどうか疑問に思う必要があります。可能な限り、unsigned算術で型を使用しないようにしますが、バイナリマスクなどの非算術演算には使用します。

'C'仕様には、実用的な理由でJavaがドロップしたいくつかの宝石がありますが、開発者の要求（クロージャーなど）によって徐々に忍び寄っています。

それがこの議論に関連しているので、私は最初のものに言及します。ポインタ値の符号なし整数演算への準拠。そして、このスレッドのトピックに関連して、Javaの署名された世界で署名されていないセマンティクスを維持することの難しさ。

ゴスリングの設計チームにアドバイスするためにデニスリッチーの代替エゴを手に入れたら、Signedに「無限大のゼロ」を与えることを提案し、すべてのアドレスオフセットリクエストが最初にALGEBRAIC RING SIZEを追加して負の値を取り除くようにしたと思います。

このようにして、アレイでスローされたオフセットがSEGFAULTを生成することはありません。たとえば、私が符号なしの動作を必要とするdoubleのRingArrayを呼び出すカプセル化されたクラスでは、「自己回転ループ」のコンテキストで：

// ...
// Housekeeping state variable
long entrycount;     // A sequence number
int cycle;           // Number of loops cycled
int size;            // Active size of the array because size<modulus during cycle 0
int modulus;         // Maximal size of the array

// Ring state variables
private int head;   // The 'head' of the Ring
private int tail;   // The ring iterator 'cursor'
// tail may get the current cursor position
// and head gets the old tail value
// there are other semantic variations possible

// The Array state variable
double [] darray;    // The array of doubles

// somewhere in constructor
public RingArray(int modulus) {
    super();
    this.modulus = modulus;
    tail =  head =  cycle = 0;
    darray = new double[modulus];
// ...
}
// ...
double getElementAt(int offset){
    return darray[(tail+modulus+offset%modulus)%modulus];
}
//  remember, the above is treating steady-state where size==modulus
// ...

上記のRingArrayは、悪意のあるリクエスタが試行した場合でも、負のインデックスから「取得」することは決してありません。以前の（負の）インデックス値を要求する正当な要求も多数あることに注意してください。

注意：外側の％modulusは正当なリクエストを逆参照しますが、内側の％modulusは露骨な悪意を-modulusよりも否定的なものから隠します。これがJavaで表示される場合+ .. + 9 || 8 + .. +仕様の場合、問題は本当に「障害を「自己回転」できないプログラマー」になるでしょう。

いわゆるJava unsigned intの「欠陥」は、上記のワンライナーで埋め合わせることができると確信しています。

PS：上記のRingArrayハウスキーピングにコンテキストを提供するためだけに、上記の「get」要素操作に一致する「set」操作の候補を次に示します。

void addElement(long entrycount,double value){ // to be called only by the keeper of entrycount
    this.entrycount= entrycount;
    cycle = (int)entrycount/modulus;
    if(cycle==0){                       // start-up is when the ring is being populated the first time around
        size = (int)entrycount;         // during start-up, size is less than modulus so use modulo size arithmetic
        tail = (int)entrycount%size;    //  during start-up
    }
    else {
        size = modulus;
        head = tail;
        tail = (int)entrycount%modulus; //  after start-up
    }
    darray[head] = value;               //  always overwrite old tail
}

残念な副作用が1つ考えられます。Java組み込みデータベースでは、32ビットのIDフィールドで使用できるIDの数は2 ^ 32ではなく2 ^ 31です（〜40億ではなく〜20億）。

私見の理由は、彼らがその間違いを実装/修正するのが面倒だからです。C / C ++プログラマーが符号なし、構造体、共用体、ビットフラグを理解していないことを示唆しています...

C言語のプログラミングを開始する寸前に、basic / bash / javaプログラマーと話していたEtherで、この言語についての知識がまったくないか、自分の頭から話しているだけです。;）

ファイルまたはハードウェアのいずれかからフォーマットを毎日取り扱っている場合、彼らは何を考えていたのでしょうか。

ここでの良い例は、自己回転ループとして符号なしバイトを使用することです。最後の文を理解していないあなたのために、一体全体であなたは自分をプログラマーと呼びます。

DC