usar titledborder setborder programacion codigo java numbers long-integer short specifications

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



titledborder java (6)

Parece que cuando escribe un número en Java, el compilador 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.


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 compilació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 .


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 short - Y y S respectivamente. Esto eliminaría la necesidad de convertir a bytes cuando se utiliza la 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 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 compilador 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 compilador java como tipo int. El compilador de tipo interno se realiza mediante el compilador 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 compilador de Java.

así que finalmente

Long l = 2147483648L;// works fine.


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 ).