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

Question

Il semble que lorsque vous tapez dans un certain nombre de Java, le compilateur lit automatiquement comme un entier, c'est pourquoi lorsque vous tapez dans la (longue) 6000000000 (pas en entier, la gamme) il va se plaindre que 6000000000 n'est pas un entier. Pour le faire taire, j'ai eu de spécifier 6000000000L. J'ai juste appris à propos de cette spécification.

Existe-il d'autres spécifications de numéro, comme pour faire court, byte, float, double? Il semble qu'il serait bon d'avoir raison (je suppose) si vous pouviez préciser le numéro de la saisie dans un court puis java n'aurais pas à le lancer - c'est une hypothèse, corrigez-moi si je me trompe. Je serais normalement de recherche, cette question moi-même, mais je ne sais pas ce que ce genre de numéro de spécification est même appelé.

S'il vous plaît laissez-moi savoir.

Answer 1

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

Si il n'y a pas de suffixe, et il est une partie intégrante de type (par exemple, 5623), il est supposé int. Si ce n'est pas une partie intégrante de type (par exemple, 3.14159), il est supposé être un double.

Dans tous les autres cas (byte, short, char), vous avez besoin de la fonte comme il n'y a pas de suffixe.

La Java spec permet à la fois supérieure et inférieure de cas des suffixes, mais les majuscules version pour longs est préféré, comme les majuscules L est moins facile à confondre avec un chiffre 1 inférieur cas l.

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

Answer 2

J'espère que vous ne m'en voudrez pas une légère tangente, mais pensé que vous pourriez être intéressés de savoir qu'en plus d' F (float), D (le double), et L (pour longtemps), une proposition a été faite d'ajouter les suffixes byte et short—Y et S respectivement. Cela permettrait d'éliminer la nécessité de fonte d'octets lors de l'utilisation de la syntaxe littérale de l'octet (ou à découvert) des tableaux. Citant l'exemple de la proposition:

AVANTAGE MAJEUR: Pourquoi la plate-forme mieux si la proposition est adoptée?

cruddy code comme

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

peut être recodifiée comme

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

Joe Darcy est de superviser Projet de Pièce de monnaie pour Java 7, et son blog a été un moyen facile de suivre ces propositions.

Answer 3

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

Answer 4

Il semblerait que ce soit bien parce que (je suppose) si vous pouviez spécifier que le nombre que vous tapez est court, java n'aurait pas à le lancer.

Comme l'analyse des littéraux a lieu au moment de la compilation, cela n'a absolument aucune incidence sur les performances. La seule raison d'avoir des suffixes short et byte serait agréable, c'est que cela conduirait à un code plus compact.

Answer 5

Considérer:

 long l = -1 >>> 1;
 

contre

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

Vous vous attendez maintenant à ce que des fragments de code dérangeants donnent la même valeur à la variable l . Nous avons donc besoin expression int littéraux à faire en int s.