Especificación del número L de Java (largo)

95

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

¿Hay otras especificaciones numéricas como short, byte, float, double? Parece que sería bueno tener estos porque (supongo) si pudiera especificar que el número que está escribiendo es corto, entonces Java no tendría que enviarlo; eso es una suposición, corríjame si me equivoco . Normalmente buscaría esta pregunta yo mismo, pero no sé cómo se llama este tipo de especificación numérica.

— jbu
fuente

174

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

Si no hay sufijo y es un tipo integral (por ejemplo 5623), se supone que es un int. Si no es un tipo integral (p 3.14159. Ej. ), Se supone que es a 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 en mayúsculas y minúsculas, pero longse prefiere la versión en mayúsculas para s, ya que la mayúscula Les menos fácil de confundir con un número 1que la minúscula l.

Consulte la sección 3.10 de JLS para obtener detalles sangrientos (consulte la definición de IntegerTypeSuffix).

— Simon Nickerson
fuente

9

Entrada tardía: eliminar las posibles fuentes de ambigüedad siempre es bueno, y no estoy en desacuerdo ... pero creo que si te confundes 1con ly 0con O(y así sucesivamente), tu prioridad es configurar correctamente la fuente (si puedes ), luego preocúpese de no perder la tecla Shift.

— davidcsb

@SimonNickerson Tengo una pregunta sobre los sufijos ... Si declaro una variable larga o doble como: long _lo = 30;y no, 30L¿esto significa que mi variable se convertirá en flotante ? O, en caso de _lo = _lo + 2.77que _loeso suceda, se convertirá en flotador aunque se declaró como largo

— luigi7up

No, las carrozas no están involucradas aquí. En el primer caso, 30es un intque se convierte automáticamente a través de una conversión de ampliación a un long. En el segundo caso, su declaración es ilegal. Tendría que lanzar explícitamente el lado derecho a largo, por ejemplo_lo = (long) (_lo + 2.77)

— Simon Nickerson

4

@DavidCesarino cambiar la fuente corrige la ambigüedad para usted, en ese editor en particular donde lo ha configurado correctamente. Cambiar de L a L corrige la ambigüedad para todos los que podrían leer su código, incluido usted mismo, cuando lee el código en un editor diferente, IDE, mira la fuente en la web (herramientas de revisión, repositorios, etc.). En mi humilde opinión, la prioridad es no perder la tecla Shift. Por cierto. ¿Qué tipo de letra me recomiendan? Me gusta el espacio único y es el predeterminado en casi todos los editores, CLI, etc. que he visto y en esta fuente ly 1( 0y Oresp.) Son bastante similares.

— dingalapadum

1

@dingalapadum Como dije, tienes razón. Eliminar las fuentes de ambigüedad es definitivamente lo correcto. Solo dije que debería intentar no usar ningún editor en el que pudiera confundirlos fácilmente. En otras palabras, la vieja sugerencia de codificar a la defensiva, pero sin depender de ello. Acerca de la fuente, es muy personal, pero siempre uso Deja Vu Sans Mono siempre que puedo porque 1) es monoespaciado; 2) no tiene ambigüedades entre personajes; y 3) Me gustan sus formas, hermosas y elegantes, casi como una buena fuente sans-serif legible (otras buenas fuentes de programación se sienten demasiado "metálicas" en mi humilde opinión).

— davidcsb

13

Espero que no le importe una ligera tangente, pero creo que le puede interesar saber que además de F(para flotante), D(para doble) y L(para largo), se ha hecho una propuesta para agregar sufijos para bytey short- Yy Srespectivamente . Esto eliminaría la necesidad de convertir a bytes cuando se usa sintaxis literal para matrices de bytes (o cortas). Citando el ejemplo de la propuesta:

MAYOR BENEFICIO: ¿Por qué es mejor la plataforma si se adopta la propuesta?

código sucio como
 byte[] stuff = { 0x00, 0x7F, (byte)0x80,  (byte)0xFF};
se puede recodificar como
 byte[] ufum7 = { 0x00y, 0x7Fy, 0x80y, 0xFFy };

Joe Darcy está supervisando Project Coin para Java 7, y su blog ha sido una manera fácil de rastrear estas propuestas.

— erickson
fuente

eso sería bueno ... Siempre he encontrado que todos los elencos son realmente molestos

— jbu

Supongo que esto no llegó a Java 7. ¿Alguna palabra sobre si se incluirá en una actualización futura o en Java 8?

— aplastar

@crush Traté de investigarlo hace unos meses y, por lo que pude ver, la propuesta había sido abandonada. Sin embargo, obtuvimos _ en literales numéricos y el 0bprefijo para literales binarios. Alarido.

— erickson

Estas propuestas probablemente se implementen en kotlin en lugar de java, ya que Oracle no quiere que la comunidad les diga cómo trabajar ... estamos en 2018 y todavía no hay nada sobre esta propuesta, lamentablemente

— JoelBonetR

11

Por defecto, cualquier tipo de datos primitivos integrales (byte, short, int, long) será tratado como tipo int por el compilador java. Para byte y short , siempre que el valor asignado a ellos esté en su rango, no hay problema y no se requiere sufijo. Si el valor asignado a byte y short excede su rango, se requiere una conversión de tipo explícita.

Ex:

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

para superar este tipo de casting realizar.

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

En el caso de un tipo de datos largo, puede aceptar el valor entero sin problemas. Supongamos que asignamos como

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

en este caso no se requiere ningún sufijo como L / l. Por defecto, el compilador Java considera que el valor 2147483647 es de tipo int. La conversión de tipos internos la realiza el compilador e int se promueve automáticamente a 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 como tipo largo por el compilador java.

así que finalmente

Long l = 2147483648L;// works fine.

— Utpal Kumar
fuente

9

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

— McDowell
fuente

1

Parece que sería bueno tener estos porque (supongo) si pudiera especificar que el número que está escribiendo es corto, entonces Java no tendría que enviarlo

Dado que el análisis de literales ocurre en tiempo de compilación, esto es absolutamente irrelevante con respecto al rendimiento. La única razón por la que tener sufijos shorty bytesería bueno es que conduce a un código más compacto.

— Michael Borgwardt
fuente

0

Para entender por qué es necesario distinguir entre literales inty long, considere:

long l = -1 >>> 1;

versus

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

Ahora, como era de esperar, ambos fragmentos de código dan el mismo valor a la variable l. Sin poder distinguir inty longliterales, ¿cuál es la interpretación de -1 >>> 1?

-1L >>> 1 // ?

o

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

Entonces, incluso si el número está en el rango común, necesitamos especificar el tipo. Si el valor predeterminado cambia con la magnitud del literal, entonces habría un cambio extraño en las interpretaciones de las expresiones simplemente por cambiar los dígitos.

Esto no se produce para byte, shorty charporque siempre son promovidos antes de realizar operaciones aritméticas y bit a bit. Podría decirse que deberían ser sufijos de tipo entero para su uso en, por ejemplo, expresiones de inicialización de matrices, pero no los hay. floatusa sufijo fy double d. Otros literales tienen tipos inequívocos, con un tipo especial para null.

— Tom Hawtin - tackline
fuente

Realmente estaría interesado en lo que quisiste decir en los días. En ambos casos obtengo 2147483647 y no entiendo por qué debería esperar algo más.

— El increíble

@TheincredibleJan Era de esperar Integer.MAX_VALUE, sin embargo, si no hubiera forma de distinguir entre literales inty long, sería ambiguo. / No recuerdo esta pregunta, pero de todos modos he aclarado mi respuesta.

— Tom Hawtin - tackline