¿Por qué el tipo resultante de una división de enteros cortos en Java no es un entero corto?

Question

consideran este código:

public class ShortDivision { 
    public static void main(String[] args) { 
     short i = 2; 
     short j = 1; 
     short k = i/j; 
    } 
} 

Compilar esto produce el error

ShortDivision.java:5: possible loss of precision 
found : int 
required: short 
     short k = i/j; 

porque el tipo de la expresión i/j es aparentemente INT, y por lo tanto deberán ser emitidos a corto.

¿Por qué el tipo de i/j no es corto?

Answer 1

Desde el Java spec:

5.6.2 numérico binario Promoción

Cuando un operador aplica promoción numérica binaria a un par de operandos, cada uno de los cuales debe denotar un valor de un tipo numérico, el Las siguientes reglas se aplican, en orden, usando conversión de ampliación (§5.1.2) para convertir operandos según sea necesario:

Si cualquier operando es de tipo doble, el otro se convierte a doble.

De lo contrario, si cualquiera de los operandos es del tipo float, el otro se convierte en float.

De lo contrario, si cualquiera de los operandos es de tipo largo, el otro se convierte en largo.

De lo contrario, ambos operandos se convierten en tipo int.

Para las operaciones binarias, pequeños tipos enteros son promovidos a int y el resultado de la operación es int.

---

EDIT: ¿Por qué es así? La respuesta corta es que Java copió este comportamiento de C. Una respuesta más larga podría tener que ver con el hecho de que todas las máquinas modernas hacen al menos cálculos nativos de 32 bits, y en realidad podría ser más difícil para algunas máquinas hacer 8 bits y Operaciones de 16 bits.

Consulte también: OR-ing bytes in C# gives int

Answer 2

En cuanto a la motivación: Imaginemos que las alternativas a este comportamiento y ver por qué no funcionan:

Alternativa 1: el resultado siempre debe ser el mismo que las entradas .

¿Cuál debería ser el resultado de agregar un int y un short?

¿Cuál debería ser el resultado de multiplicar dos pantalones cortos? El resultado en general se ajustará a un int, pero como truncamos a corto, la mayoría de las multiplicaciones fallarán en silencio. Casting a un int después no ayudará.

Alternativa 2: el resultado siempre debe ser el tipo más pequeño que pueda representar todas las salidas posibles.

Si el tipo de devolución fue corto, la respuesta no siempre podría ser representativa.

Un valor bajo puede contener valores -32,768 a 32,767. Entonces, este resultado causará desbordamiento:

short result = -32768/-1; // 32768: not a short 

Así que su pregunta es: ¿por qué la adición de dos ints no devuelve un largo? ¿Qué debería ser la multiplicación de dos puntos? Un largo? ¿Un BigNumber para cubrir el caso de cuadrar el valor mínimo entero?

Alternativa 3: Elija lo más probable que las personas quieren mayor parte del tiempo

Así, el resultado debería ser:

• int para multiplicar dos cortos, o cualquier operaciones int.
• corto si se suman o restan cortos, dividiendo un corto por cualquier tipo de entero, multiplicando dos bytes, ...
• byte si bitshifting un byte a la derecha, int si bitshifting a la izquierda.
• etc ...

recordando todos los casos especiales serían difíciles si no hay una lógica fundamental para ellos. Es más simple decir: el resultado de operaciones enteras es siempre un int.

Answer 3

Es solo una opción de diseño para ser coherente con C/C++, que eran los idiomas dominantes cuando se diseñó Java.

Por ejemplo, i * j podría implementarse de modo que el tipo se promueva desde byte => short, short => int, e int => long, y esto evitaría los desbordamientos pero no lo hace. (Lo hace en algunos idiomas). Se podría usar la conversión si se deseaba el comportamiento actual, pero la pérdida de algunos bits sería clara.

De manera similar, se podría solicitar i/j desde byte/short => float o int/long => double.