2008-11-25 11 views
53

Puedo crear una longitud literal al agregar una L al valor; ¿Por qué no puedo crear un corto o un byte literal de alguna manera similar? ¿Por qué necesito usar un int literal con un molde?¿Por qué no hay byte o literales cortos en Java?

Y si la respuesta es "Como no había un breve literal en C", ¿por qué no hay literales cortos en C?

Esto realmente no afecta mi vida de ninguna manera significativa; es bastante fácil escribir (abreviado) 0 en lugar de 0S o algo así. Pero la inconsistencia me da curiosidad; es una de esas cosas que te molestan cuando te levantas tarde en la noche. En algún momento, alguien tomó una decisión de diseño para permitir el ingreso de literales para algunos de los tipos primitivos, pero no para todos. ¿Por qué?

Respuesta

15

En C, int al menos se suponía que tenía el tamaño de palabra "natural" de la CPU y long probablemente era el tamaño de palabra "más grande" (no estoy seguro en esa última parte, pero también explicaría por qué int y long tienen el mismo tamaño en x86).

Ahora, mi conjetura es: para int y long, hay una representación natural que encaja exactamente en los registros de la máquina. Sin embargo, en la mayoría de las CPU, los tipos más pequeños byte y short tendrían que rellenarse de int antes de ser utilizados. Si ese es el caso, también puedes tener un elenco.

8

Sospecho que es un caso de "no agregue nada al idioma a menos que realmente agregue valor", y se consideró que agregaba poco valor como para no valer la pena. Como ya dijiste, es fácil moverse y, francamente, rara vez es necesario (solo para la desambiguación).

Lo mismo es cierto en C#, y nunca me he perdido particularmente en ninguno de los dos idiomas. Lo que sí echo de menos en Java es un tipo de byte sin signo :)

+4

sí, por favor añadir byte sin signo :(. Para el tema que nos ocupa, creo que vale la pena mencionar que hay un largo iteral porque un int literal no puede representar todos los valores de un largo. Pero un int puede representar todos los valores de un corto, por otro lado. –

+0

Pero creo que agrega valor; no tener que emitir puede ser una gran ventaja. 'short val = (short) (val + 10) 'es simplemente molesto, aunque Java también debería permitir la adición de' short's para que funcione. – mjaggard

+0

@mjaggard: Se trata de agregar * valor suficientemente pequeño * para que no valga la pena. Es un poco fastidioso, pero lejos del mayor problema ... –

5

Otra razón podría ser que la JVM no sabe sobre el byte corto y el byte. Todos los cálculos y el almacenamiento se realizan con ints, longs, floats y dobles dentro de la JVM.

+1

De acuerdo, pero ¿es eso cierto en cada JVM? E incluso si lo es, ¿debería la definición del lenguaje depender realmente de los detalles de implementación de la VM en la que se ejecuta? ¿No debería ser al revés? –

+0

Es parte de la especificación de JVM, entonces sí: la JVM no tiene forma de saber qué tipo es realmente el valor que maneja. (Excepto para algunas operaciones como acceso a arreglos, donde existen códigos de operación separados). –

+5

El almacenamiento * no * siempre se realiza con entradas, etc. El ejemplo obvio es una matriz de bytes, que sin duda se almacena como una matriz de bytes en lugar de como partes. Ver también http://stackoverflow.com/questions/229886/size-of-a-byte-in-memory-java –

2

Hay varias cosas a considerar.

1) Como se mencionó anteriormente, la JVM no tiene noción de byte o tipos cortos. En general, estos tipos no se utilizan en el cálculo a nivel de JVM; entonces uno puede pensar que habría menos uso de estos literales.

2) Para la inicialización de byte y variables cortas, si la expresión int es constante y en el rango permitido del tipo, se convierte implícitamente al tipo de destino.

3) Uno siempre puede emitir el literal, ex (corto) 10

Cuestiones relacionadas