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

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

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

    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 que es un int . Si no es un tipo integral (p. Ej., 3.14159 ), se supone que es un double .

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

    La especificación de Java permite los sufijos de mayúsculas y minúsculas, pero se prefiere la versión de mayúsculas para los long , ya que la L mayúscula es menos fácil de confundir con un número 1 que la minúscula l .

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

    Espero que no te importe una ligera tangente, pero pensaste que podrías estar interesado en saber que además de F (para flotar), D (para el doble) y L (para el largo), se ha hecho una propuesta para agregar sufijos para byte y shortY y S respectivamente. Esto eliminaría la necesidad de convertir a bytes cuando se utiliza la syntax 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 cruddy como

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

    puede ser recodificado como

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

    Joe Darcy supervisa Project Coin para Java 7, y su blog ha sido una forma fácil de seguir estas propuestas.

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

    Por defecto, cualquier tipo de datos de primitiva integral (byte, short, int, long) será tratado como int type por el comstackdor de java. Para byte y corto , 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 corto excede su rango, se requiere una conversión de tipo explícita.

    Ex:

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

    para vencer esto, realiza un casting tipo.

     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 ninguna molestia. Supongamos que asignamos como

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

    en este caso, no se requiere un sufijo como L / l. Por defecto, el valor 2147483647 es considerado por el comstackdor java como tipo int. El comstackdor de tipo interno se realiza mediante el comstackdor y int se promociona automáticamente a Tipo largo.

     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 comstackdor de Java.

    así que finalmente

     Long l = 2147483648L;// works fine. 

    Parece que sería bueno tenerlos porque (supongo) si pudieras especificar que el número que estás escribiendo es corto, entonces Java no tendría que lanzarlo

    Como el análisis sintáctico de literales ocurre en tiempo de comstackción, esto es absolutamente irrelevante en lo que respecta al rendimiento. La única razón para tener sufijos short y de byte sería bueno es que conduzca a un código más compacto.

    Considerar:

     long l = -1 >>> 1; 

    versus

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

    Ahora esperas que los fragmentos de código den el mismo valor a la variable l . Por lo tanto, necesitamos que la expresión en int literales se haga como int .