Java de L du nombre (long) spécification

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 corriger cela, 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é.

InformationsquelleAutor jbu | 2009-04-20

167

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é être un 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 spécifique.

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 que les minuscules l.

Voir le JLS section 3.10 pour les détails croustillants (voir la définition de IntegerTypeSuffix).
- En retard: suppression des sources potentielles d'ambiguïté est toujours bon, et je ne suis pas en désaccord... mais je crois que si vous vous trouvez confus 1 avec l et 0 avec O (et ainsi de suite), votre prioritaire est de définir la police de droite (si vous pouvez), puis vous soucier de faire en sorte de ne pas manquer la touche Maj enfoncée.
- J'ai une question à propos des suffixes... Si je déclare un long ou double variable comme: long _lo = 30; et pas 30L est-ce à dire ma variable sera converti en float ? Ou en cas de _lo = _lo + 2.77 que _lo sera intégré dans float bien qu'il a été déclaré que long
- Non, les flotteurs ne sont pas en cause ici. Dans le premier cas, 30 est un int qui est automatiquement converti via un élargissement de la conversion à une long. Dans le second cas, votre déclaration est illégal. Vous devez convertir explicitement le côté droit, à la longue, par exemple _lo = (long) (_lo + 2.77)
- la modification de la police résout l'ambiguïté pour vous - dans l'éditeur, où vous avez le mettre droit. Modification de l à L résout l'ambiguïté pour tout le monde qui pourrait jamais lire votre code, y compris vous-même lorsque vous êtes la lecture du code dans un autre Éditeur, IDE, à la recherche à la source sur le web (la révision des outils, des référentiels, etc..). À mon humble avis, la priorité est de ne pas manquer la touche Maj enfoncée. Btw. quelle police recommandez-vous? J'aime monospace et c'est la valeur par défaut dans presque tous les éditeurs, CLIs, etc que j'ai voir et dans cette police l et 1 (0 et O resp.) sont assez semblables.
- Comme je l'ai dit, vous avez raison. La suppression des sources d'ambiguïté est certainement une bonne chose à faire. J'ai juste dit que vous devriez essayer de ne pas utiliser n'importe quel éditeur où l'on pourrait facilement confondre. En d'autres mots, la vieille suggestion de codage défensivement, mais pas selon elle. Sur la police, c'est très personnel, mais je l'utilise toujours Déjà-Vu Sans Mono dès que je peux, parce que 1) c'est à chasse fixe; 2) il n'a pas d'ambiguïtés entre les personnages; et 3) j'aime ses formes, belle et gracieuse, presque comme un bon, lisible sans-serif (autre bonne programmation des polices de se sentir trop "métallique" à mon humble avis).
- J'ai l'habitude d'utiliser Roboto mono sur mon IDEs, il le rend facile à lire.
InformationsquelleAutor Simon Nickerson
13

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 de F (pour float), D (double), et L (pour longtemps), une proposition a été faite à des suffixes pour 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.
- ce serait sympa...j'ai toujours trouvé que toutes les distributions sont vraiment ennuyeux
- Je le prends ce ne pas le faire dans Java 7. Aucun mot sur si il va le faire dans une future mise à jour ou Java 8?
- J'ai essayé de regarder dans quelques mois en arrière, et aussi loin que je pouvais dire, la proposition a été abandonnée. Nous avons eu des _ dans les littéraux numériques et la 0b préfixe binaire littéraux bien. Wouah.
- Cette propositions sont probablement mis en œuvre sur kotlin au lieu de java, oracle ne voulez pas que la communauté leur dire comment travailler... nous sommes en 2018 et toujours rien au sujet de cette proposition, malheureusement
InformationsquelleAutor erickson
8

Ces sont des littéraux et sont décrits dans section 3.10 du langage Java, spec.

InformationsquelleAutor McDowell
8

Par défaut, toutes les intégrales de type de données primitif (byte, short, int, long) seront traités comme des int type par le compilateur java. Pour octet et court, tant que la valeur qui leur est attribuée est dans leur gamme, il n'y a pas de problème et pas de suffixe nécessaire. Si la valeur attribuée à octet et court dépasse leur gamme, explicite la conversion de type est nécessaire.

Ex:
```
byte b = 130; //CE: range is exceeding.
```
pour surmonter cette effectuer la conversion de type.
```
byte b = (byte)130; //valid, but chances of losing data is there.
```
Dans le cas de données de type long, il peut accepter la valeur entière sans aucun tracas. Supposons que nous assignons comme
```
Long l = 2147483647; //which is max value of int
```
dans ce cas pas de suffixe comme L/L est nécessaire. Par défaut la valeur 2147483647 est considéré par le compilateur java est de type int. Interne, la conversion de type est faite par le compilateur et l'int est auto promu type Long.
```
Long l = 2147483648; //CE: value is treated as int but out of range 
```
Ici, nous avons besoin de mettre le suffixe comme L pour traiter le littéral 2147483648 que le type long par le compilateur java.

donc finalement
```
Long l = 2147483648L;//works fine.
```
InformationsquelleAutor Utpal Kumar
1

Il semble qu'il serait bon de
avoir parce que (je suppose) si vous pouviez
spécifier le nombre que vous tapez est
un court puis java ne pas avoir à
fonte il

Depuis l'analyse de littéraux qui se passe au moment de la compilation, ce n'est absolument pas pertinent en ce qui concerne les performances. La seule raison d'avoir short et byte suffixes serait bien c'est qu'il conduit à code plus compact.

InformationsquelleAutor Michael Borgwardt
0

Considérer:
```
long l = -1 >>> 1;
```
contre
```
int a = -1;
long l = a >>> 1;
```
Maintenant, vous attendez la peine fragments de code à donner la même valeur à la variable l. Nous avons donc besoin d'expression sur int littéraux à faire comme ints.

InformationsquelleAutor Tom Hawtin - tackline

Vous devez vous connecter pour publier un commentaire.