Pourquoi Java ne prend-il pas en charge les ints non signés?

Question

Pourquoi ne pas Java d'inclure le support pour des entiers non signés?

Il me semble être une omission étrange, étant donné qu'ils permettent d'écrire du code qui est moins susceptible de produire des débordements sur inattendue de la grande entrée.

En outre, en utilisant des entiers non signés peuvent être une forme d'auto-documentation, car ils indiquent que la valeur de la unsigned int a l'intention de tenir est jamais censé être négatif.

Enfin, dans certains cas, des entiers non signés peuvent être plus efficaces pour certaines opérations, telles que la division.

Quel est l'inconvénient d'inclure ces?

Answer 1

C'est à partir d'un entretien avec Gosling et autres, au sujet de la simplicité:

Gosling: Pour moi, comme une langue designer, dont je n'ai pas vraiment me sens comme ces jours-ci, ce "simple" vraiment fini le sens je pourrais attendre J. Aléatoire Développeur de tenir la spec dans sa tête. Cette définition dit que, par exemple, Java ne l'est pas, et en fait, beaucoup de ces langues à la fin avec beaucoup de coin affaires, des choses que personne ne comprend vraiment. Quiz tout développeur C sur non signé, et très rapidement, vous découvrez que presque aucun des développeurs C vraiment comprendre ce qui se passe avec non signé, ce unsigned l'arithmétique est. Des choses comme ça fait C complexe. Le langage Java est, je pense, assez simple. Les bibliothèques que vous avez à regarder.

Answer 2

Lire entre les lignes, je pense que la logique était quelque chose comme ceci:

• généralement, la Java concepteurs ont voulu simplifier le répertoire des types de données disponibles
• pour un usage quotidien, ils ont estimé que le besoin le plus commun a été signé pour les types de données
• pour la mise en œuvre de certains de ces algorithmes, non signé arithmétique est parfois nécessaire, mais le genre de programmeurs qui serait mise en œuvre de ces algorithmes aurait également la connaissance de "travailler ronde" faire unsigned de l'arithmétique à la signature des types de données

Pour la plupart, je dirais que c'était une décision raisonnable. Éventuellement, j'aurais:

• faites octet non signé, ou au moins fournir un signed/unsigned alternatives, éventuellement avec des noms différents, pour ce seul type de données (signé est bon pour des raisons de cohérence, mais quand vous avez besoin d'un octet signé?)
• fait disparaître la "court" (quand avez-vous la dernière utilisation de 16 bits signé de l'arithmétique?)

Pourtant, avec un peu de kludging, les opérations sur des valeurs non signées jusqu'à 32 bits ne sont pas tooo mauvais, et la plupart des gens n'ont pas besoin de 64 bits non signé de la division ou de comparaison.

Answer 3

Ceci est une ancienne question et pat a fait brièvement mention char, j'ai juste pensé que je devrais élargir ces pour les autres, qui va regarder cette en bas de la route. Prenons regarder de plus près les types primitifs de Java:

octet de 8 bits entier signé

court - 16 bits entier signé

int - entier signé 32 bits

long de 64 bits entier signé

char - caractères 16 bits (entier non signé)

Bien que le char ne prend pas en charge non signé de l'arithmétique, essentiellement, il peut être traité comme un entier non signé. Vous devez explicitement exprimés opérations arithmétiques de retour en char, mais il ne vous fournir un moyen pour spécifier les nombres non signés.

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--;

Oui, il n'y a pas de support direct pour les entiers non signés (évidemment, je n'aurais pas à lancer la plupart de mes opérations de retour en char si il y avait un soutien direct). Cependant, il existe certainement un unsigned type de données primitif. J'aurais aimé avoir vu un octet non signé, mais je suppose que le doublement de la mémoire de coûts et d'utiliser plutôt le char est une option viable.

Edit:

Avec JDK8 il y aura de nouvelles Api pour Longtemps et Entier qui fournissent des méthodes d'assistance en cas de traitement de longue et int les valeurs comme des valeurs non signées. En outre, la Goyave fournit un certain nombre de méthodes d'aide à faire la même chose pour les types integer, permettant de combler le vide laissé par l'absence de la prise en charge native pour les entiers non signés.

Answer 4

Dès que les ints signés et non signés sont mélangés dans une expression, les choses commencent à devenir désordonnées et vous perdrez probablement des informations. Restreindre Java aux entiers signés ne fait que clarifier les choses. Je suis heureux de ne pas avoir à m'inquiéter de toute l'affaire signée / non signée, bien que je rate parfois le huitième bit d'un octet. :)

Answer 5

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

Ce type dit parce que la norme C définit les opérations impliquant des signatures non signées et signées pour être traitées comme non signées. Cela pourrait entraîner des entiers signés négatifs à se transformer en un entier non signé, ce qui pourrait causer des bogues.