L número de especificación de Java (largo)

Question

Parece que cuando se escribe en un número en Java, el compilador lee automáticamente como un entero, por lo que cuando se escribe en 6000000000 (largo) (no en el rango de número entero) se quejan de que 6000000000 no es un entero . Para corregir esto, tuve que especificar 6000000000L. Acabo de aprender acerca de esta especificación.

¿Hay otras especificaciones numéricas como para abreviar, byte, float, double? Parece que estos serían bueno tener porque (supongo) si se puede especificar el número que está escribiendo es un corto luego de Java no tener que echarlo - esto es una suposición, me corrija si estoy equivocado . Yo normalmente buscar esta pregunta a mí mismo, pero no sé lo que este tipo de especificación de números se llama incluso.

Answer 1

Hay sufijos específicos para long (por ejemplo 39832L), float (por ejemplo 2.4f) y double (por ejemplo -7.832d).

Si no hay sufijo, y es un tipo integral (por ejemplo 5623), se supone ser una int. Si no es un tipo integral (por ejemplo 3.14159), se supone ser una double.

En todos los demás casos (byte, short, char), necesita el elenco ya que no hay sufijo específico.

La especificación Java permite sufijos caso tanto superior e inferior, pero se prefiere la versión en mayúsculas para longs, según el caso L superior es menos fácil de confundir con un 1 numeral que en el caso l inferior.

Vea la sección JLS 3.10 para los detalles morbosos (ver la definición de IntegerTypeSuffix).

Answer 2

Espero que no le importe un ligero tangente, pero pensé que podría estar interesado en saber que además de F (por flotación), D (por matrimonio), y L (por mucho tiempo), una propuesta se ha hecho añadir sufijos para byte y short-Y y S respectivamente. Esto eliminaría la necesidad de echar a bytes cuando se utilice la sintaxis literal de bytes (o cortos) matrices. Citando el ejemplo de la propuesta:

  

ventaja importante: ¿Por qué es la plataforma   mejor si se adopta la propuesta?

     

Código sucia como

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

     

se pueden recodificar como

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

Joe Darcy está supervisando la moneda Proyecto para Java 7, y su blog ha sido una manera fácil realizar un seguimiento de estas propuestas.

Answer 3

Estos son literales y se describen en sección 3.10 de la especificación del lenguaje Java.

Answer 4

Por defecto cualquier tipo integral primitiva de datos (byte, short, int, long) serán tratados como int tipo de compilador Java. Para bytes y resumen , siempre y cuando el valor asignado a ellos está en su rango, no hay ningún problema y sin sufijo necesario. Si el valor asignado a bytes y resumen es superior a su rango, se requiere conversión de tipos explícita.

Ejemplo:

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

para superar este realice tipo de colada.

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

En caso de larga tipo de datos, que puede aceptar el valor entero sin ninguna molestia. Supongamos que asignamos como

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

en este caso no se requiere el sufijo como L / l. Por valor predeterminado 2147483647 es considerado por el compilador Java es tipo int. fundición de tipo interno se realiza mediante compilador y int es de auto promovidos al tipo Long.

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

Aquí tenemos que poner el sufijo como L para tratar el literal 2147483648 siempre el tipo de compilador Java.

Así que finalmente

Long l = 2147483648L;// works fine.

Answer 5

  

Parece que estos serían buenos para   tener porque (supongo) si pudiera   especifique el número que está escribiendo es   a continuación, un breve java no tendría que   echarlo

Desde el análisis de literales que sucede en tiempo de compilación, esto es absolutamente irrelevante en cuanto a rendimiento. La única razón por la que tiene short y byte sufijos sería bueno es que conducen a un código más compacto.

Answer 6

Considere lo siguiente:

long l = -1 >>> 1;

frente

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

Ahora usted esperaría molestar a fragmentos de código para dar el mismo valor a l variable. Por lo que necesitamos la expresión en los literales a int hacerse como ints.