Specifica del numero L (lungo) di Java

Sembra che quando digiti un numero in Java, il compilatore lo legge automaticamente come un numero intero, motivo per cui quando digiti (lungo) 6000000000(non nell'intervallo del numero intero) si lamenterà che 6000000000non è un numero intero. Per correggere questo, ho dovuto specificare 6000000000L. Ho appena saputo di questa specifica.

Esistono altre specifiche numeriche come short, byte, float, double? Sembra che questi sarebbero buoni da avere perché (presumo) se potessi specificare il numero che stai digitando è un breve, java non dovrebbe lanciarlo - questa è un'ipotesi, correggimi se sbaglio . Normalmente cercherò questa domanda da solo, ma non so nemmeno come viene chiamato questo tipo di specifica del numero.

Esistono suffissi specifici per long(eg 39832L), float(eg 2.4f) e double(eg -7.832d).

Se non è presente alcun suffisso ed è un tipo integrale (ad esempio 5623), si presume che sia un int. Se non è un tipo integrale (ad esempio 3.14159), si presume che sia a double.

In tutti gli altri casi ( byte, short, char), è necessario il cast in quanto non v'è alcun suffisso specifico.

Le specifiche Java consentono suffissi sia maiuscoli che minuscoli, ma longè preferibile la versione maiuscola per s, poiché Lè meno facile confondere le maiuscole con un numero 1rispetto alle minuscole l.

Vedere la sezione JLS 3.10 per i dettagli cruenti (vedere la definizione di IntegerTypeSuffix).

Spero non ti dispiaccia una leggera tangente, ma ho pensato che potresti essere interessato a sapere che oltre a F(per float), D(per double) e L(per lungo), è stata fatta una proposta per aggiungere suffissi per bytee short- Ye Srispettivamente . Ciò eliminerebbe la necessità di eseguire il cast su byte quando si utilizza la sintassi letterale per array di byte (o brevi). Citando l'esempio della proposta:

VANTAGGIO PRINCIPALE: perché la piattaforma è migliore se la proposta viene adottata?

codice rozzo come

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

può essere ricodificato come

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

Joe Darcy sta supervisionando Project Coin per Java 7 e il suo blog è stato un modo semplice per tenere traccia di queste proposte.

Per impostazione predefinita, qualsiasi tipo di dati primitivo integrale (byte, short, int, long) verrà trattato come tipo int dal compilatore java. Per byte e short , fintanto che il valore loro assegnato è nel loro intervallo, non ci sono problemi e non sono richiesti suffissi. Se il valore assegnato a byte e short supera il loro intervallo, è richiesto il casting esplicito del tipo.

Ex:

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

per ovviare a questo tipo di casting eseguire.

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

In caso di tipo di dati lungo, può accettare il valore intero senza problemi. Supponiamo di assegnare like

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

in questo caso non è richiesto alcun suffisso come L / l. Per impostazione predefinita, il valore 2147483647 è considerato dal compilatore java è di tipo int. Il casting del tipo interno viene eseguito dal compilatore e int viene promosso automaticamente al tipo Long.

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

Qui dobbiamo mettere il suffisso come L per trattare il letterale 2147483648 come tipo lungo dal compilatore java.

così finalmente

Long l = 2147483648L;// works fine.

Questi sono letterali e sono descritti nella sezione 3.10 delle specifiche del linguaggio Java.

Sembra che questi sarebbero buoni da avere perché (presumo) se potessi specificare il numero che stai digitando è breve, java non dovrebbe lanciarlo

Poiché l'analisi dei letterali avviene in fase di compilazione, ciò è assolutamente irrilevante per quanto riguarda le prestazioni. L'unico motivo shortper cui bytesarebbe bello avere e suffissi è che porta a un codice più compatto.

Per capire perché è necessario distinguere tra inte longletterali, considera:

long l = -1 >>> 1;

contro

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

Ora, come ci si aspetterebbe giustamente, entrambi i frammenti di codice danno lo stesso valore a variable l. Senza essere in grado di distinguere inte longletterali, qual è l'interpretazione di -1 >>> 1?

-1L >>> 1 // ?

o

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

Quindi, anche se il numero è nell'intervallo comune, è necessario specificare il tipo. Se il valore predefinito cambiava con l'ampiezza del letterale, ci sarebbe stato uno strano cambiamento nelle interpretazioni delle espressioni semplicemente cambiando le cifre.

Questo non si verifica per byte, shorte charperché sono sempre promosso prima di eseguire operazioni aritmetiche e bit a bit. Probabilmente dovrebbero essere suffissi di tipo intero da utilizzare, ad esempio, in espressioni di inizializzazione di array, ma non c'è. floatusa il suffisso fe double d. Altri letterali hanno tipi non ambigui, con un tipo speciale per null.