Especificação L Número L de Java (Longo)

Question

Parece que quando você digita um número em Java, o compilador o lê automaticamente como um número inteiro, e é por isso que quando você digita (longo) 6000000000 (não no alcance do número inteiro), ele reclamará que 6000000000 não é um número inteiro. Para corrigir isso, eu tive que especificar 6000000000L. Acabei de aprender sobre essa especificação.

Existem outras especificações de números, como para curto, byte, flutuar, dobrar? Parece que seria bom ter, porque (suponho) se você pudesse especificar o número em que está digitando é um curto, então Java não precisaria lançá -lo - isso é uma suposição, corrija -me se eu estiver errado . Eu normalmente pesquisaria essa pergunta, mas não sei como esse tipo de especificação de números é chamado.

Answer 1

Existem sufixos específicos para long (por exemplo: 39832L), float (por exemplo: 2.4f) e double (por exemplo: -7.832d).

Se não houver sufixo, e é um tipo integral (por exemplo 5623), supõe -se que seja um int. Se não for um tipo integral (por exemplo 3.14159), supõe -se que seja um double.

Em todos os outros casos (byte, short, char), você precisa do elenco, pois não há sufixo específico.

A especificação Java permite sufixos superior e inferior, mas a versão mais alta para longs é preferido, como o maiúsculo L é menos fácil de confundir com um numeral 1 do que a minúscula l.

Veja o JLS Seção 3.10 para os detalhes sangrentos (veja a definição de IntegerTypeSuffix).

Answer 2

Espero que você não se importe com uma ligeira tangente, mas pensei que pode estar interessado em saber disso além F (para flutuação), D (para o dobro) e L (por muito tempo), Uma proposta foi feita para adicionar sufixos para byte e short—Y e S respectivamente. Isso eliminaria a necessidade de lançar para bytes ao usar sintaxe literal para matrizes de byte (ou curtas). Citando o exemplo da proposta:

Grande benefício: por que a plataforma é melhor se a proposta for adotada?

Código cruel como

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

pode ser recodificado como

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

Joe Darcy está supervisionando o Projeto Coin para Java 7 e Seu blog tem sido uma maneira fácil de rastrear essas propostas.

Answer 3

Estes são literais e são descritos em Seção 3.10 da especificação da linguagem Java.

Answer 4

Por padrão, qualquer tipo de dados primitivo integral (byte, curto, int, longo) será tratado como int Tipo por compilador Java. Por byte e curto, desde que o valor atribuído a eles esteja em seu intervalo, não há problema e nenhum sufixo necessário. Se o valor atribuído a byte e curto Exceda o seu alcance, é necessária fundição do tipo explícito.

Ex:

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

Para superar esse elenco de execução do tipo.

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

Em caso de tipo de dados longo, ele pode aceitar o valor inteiro sem qualquer aborrecimento. Suponha que atribuímos como

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

Nesse caso, nenhum sufixo como L/L é necessário. Por padrão padrão 2147483647, é considerado pelo compilador Java é o tipo int. A fundição do tipo interno é feita pelo compilador e o INT é promovido automaticamente a um tipo longo.

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

Aqui precisamos colocar o sufixo como l para tratar o literal 2147483648 como tipo longo do compilador Java.

Então, finalmente

Long l = 2147483648L;// works fine.

Answer 5

Parece que seria bom ter, porque (suponho) se você pudesse especificar o número em que você está digitando é um curto, então Java não precisaria lançá -lo

Como a análise dos literais acontece no momento da compilação, isso é absolutamente irrelevante em relação ao desempenho. A única razão de ter short e byte Os sufixos seriam bons é que ele leve a um código mais compacto.

Answer 6

Considerar:

long l = -1 >>> 1;

contra

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

Agora você esperaria que os fragmentos de código de incomodar dessem o mesmo valor à variável l. Então, precisamos de expressão em int literais a serem feitos como ints.