Spécification du numéro L de Java (long)

Il semble que lorsque vous tapez un nombre en Java, le compilateur le lit automatiquement comme un entier, c'est pourquoi lorsque vous tapez (long) 6000000000(pas dans la plage d'entiers), il se plaindra que ce 6000000000n'est pas un entier. Pour corriger cela, j'ai dû préciser 6000000000L. Je viens d'apprendre cette spécification.

Existe-t-il d'autres spécifications numériques comme pour court, octet, flottant, double? Il semble que ce serait bien d'avoir parce que (je suppose) si vous pouviez spécifier le nombre que vous saisissez est un court alors java n'aurait pas à le lancer - c'est une hypothèse, corrigez-moi si je me trompe . Normalement, je chercherais moi-même cette question, mais je ne sais pas comment s'appelle même ce type de spécification de nombre.

Il existe des suffixes spécifiques pour long(par exemple 39832L), float(par exemple 2.4f) et double(par exemple-7.832d ).

S'il n'y a pas de suffixe et qu'il s'agit d'un type intégral (par exemple 5623), il est supposé être un int. S'il ne s'agit pas d'un type intégral (par exemple 3.14159), il est supposé être undouble .

Dans tous les autres cas ( byte, short,char ), vous avez besoin du casting car il n'y a pas de suffixe spécifique.

La spécification Java autorise les suffixes majuscules et minuscules, mais la version majuscule pour longs est préférée, car les majuscules Lsont moins faciles à confondre avec un chiffre1 que les minuscules l.

Voir la section 3.10 de JLS pour les détails sanglants (voir la définition de IntegerTypeSuffix).

J'espère qu'une légère tangente ne vous dérangera pas, mais j'ai pensé que cela pourrait vous intéresser de savoir qu'en plus F(pour float), D(pour double) et L(pour longtemps), une proposition a été faite d'ajouter des suffixes pour byteet short- Yet Srespectivement . Cela éliminerait le besoin de transtyper en octets lors de l'utilisation d'une syntaxe littérale pour des tableaux d'octets (ou courts). Citant l'exemple de la proposition:

AVANTAGE MAJEUR: Pourquoi la plateforme est-elle meilleure si la proposition est adoptée?

code grossier comme

 byte[] stuff = { 0x00, 0x7F, (byte)0x80,  (byte)0xFF};

peut être recodé comme

 byte[] ufum7 = { 0x00y, 0x7Fy, 0x80y, 0xFFy };

Joe Darcy supervise Project Coin pour Java 7, et son blog a été un moyen facile de suivre ces propositions.

Par défaut, tout type de données primitif intégral (byte, short, int, long) sera traité comme type int par le compilateur java. Pour byte et short , tant que la valeur qui leur est assignée est dans leur plage, il n'y a aucun problème et aucun suffixe requis. Si la valeur attribuée à byte et short dépasse leur plage, une conversion de type explicite est requise.

Ex:

byte b = 130; // CE: range is exceeding.

pour surmonter cette coulée de type effectuer.

byte b = (byte)130; //valid, but chances of losing data is there.

En cas de type de données long, il peut accepter la valeur entière sans aucun problème. Supposons que nous attribuions comme

Long l = 2147483647; //which is max value of int

dans ce cas, aucun suffixe comme L / l n'est requis. Par défaut, la valeur 2147483647 est considérée par le compilateur java de type int. Le cast de type interne est effectué par le compilateur et int est automatiquement promu en type Long.

Long l = 2147483648; //CE: value is treated as int but out of range 

Ici, nous devons mettre le suffixe L pour traiter le littéral 2147483648 comme un type long par le compilateur java.

donc finalement

Long l = 2147483648L;// works fine.

Ce sont des littéraux et sont décrits dans la section 3.10 de la spécification du langage Java.

Il semble que ce serait bien d'avoir parce que (je suppose) si vous pouviez spécifier le nombre que vous tapez est un court alors java n'aurait pas à le lancer

Étant donné que l'analyse des littéraux se produit au moment de la compilation, cela n'a absolument aucune importance en termes de performances. La seule raison d'avoir shortetbyte suffixes serait bien est qu'il conduit à un code plus compact.

Pour comprendre pourquoi il est nécessaire de faire la distinction entre intet longlittéraux, considérez:

long l = -1 >>> 1;

contre

int a = -1;
long l = a >>> 1;

Maintenant, comme vous vous en doutez, les deux fragments de code donnent la même valeur à variable l. Sans pouvoir distinguer intet longlittéralement, quelle est l'interprétation de -1 >>> 1?

-1L >>> 1 // ?

ou

(int)-1 >>> 1 // ?

Donc, même si le nombre est dans la plage commune, nous devons spécifier le type. Si la valeur par défaut changeait avec la magnitude du littéral, alors il y aurait un changement étrange dans les interprétations des expressions simplement en changeant les chiffres.

Cela ne se produit pas byte, shortet charparce qu'ils sont toujours promu avant d' effectuer des opérations arithmétiques et au niveau du bit. On peut soutenir qu'il devrait s'agir de suffixes de type entier à utiliser, par exemple, dans des expressions d'initialisation de tableau, mais ce n'est pas le cas. floatutilise le suffixe fet double d. D'autres littéraux ont des types non ambigus, avec un type spécial pour null.