为什么字节和短分区在Java中导致int? [英] Why byte and short division results in int in Java?

查看:172
本文介绍了为什么字节和短分区在Java中导致int?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在Java中,如果我们划分 byte s, short s或 int s,我们总是得到 int 。如果其中一个操作数是 long ,我们将获得 long

In Java, if we divide bytes, shorts or ints, we always get an int. If one of the operands is long, we'll get long.

我的问题是 - 为什么字节除以 byte short ?为什么总是 int

My question is - why does byte or short division not result in byte or short? Why always int?

显然我不是在寻找因为JLS这么说的回答,我是在Java语言中询问此设计决策的技术原理。

Apparently I'm not looking for the "because JLS says so" answer, I am asking about the technical rationale for this design decision in the Java language.

考虑以下代码示例:

    byte byteA = 127;
    byte byteB = -128;
    short shortA = 32767;
    short shortB = -32768;
    int intA = 2147483647;
    int intB = - -2147483648;
    long longA = 9223372036854775807L;
    long longB = -9223372036854775808L;


    int byteAByteB = byteA/byteB;
    int byteAShortB = byteA/shortB;
    int byteAIntB = byteA/intB;
    long byteALongB = byteA/longB;

    int shortAByteB = shortA/byteB;
    int shortAShortB = shortA/shortB;
    int shortAIntB = shortA/intB;
    long shortALongB = shortA/longB;

    int intAByteB = intA/byteB;
    int intAShortB = intA/shortB;
    int intAIntB = intA/intB;
    long intALongB = intA/longB;

    long longAByteB = longA/byteB;
    long longAShortB = longA/shortB;
    long longAIntB = longA/intB;
    long longALongB = longA/longB;

byteA 除以 byteB 不能只是一个字节,可以吗?

那么为什么 byteAByteB 必须是 INT ?为什么不能 shortALongB

为什么 intALongB 必须 long ,结果总是适合 int ,不是吗?

byteA divided by byteB can't be anything but a byte, can it?
So why must byteAByteB be an int? Why can't shortALongB be short?
Why does intALongB have to be long, the result will always fit int, will it not?

更新

正如@Eran所指出的那样,( byte)-128 /(byte)-1 结果为 128 ,这不符合字节。但为什么不那么?

As @Eran pointed out, (byte)-128/(byte)-1 results in 128 which does not fit a byte. But why not short then?

更新2

接下来,当@Eran指出(再次)时,(int)-2147483648 /(int)-1 也不适合 int 但结果仍是 int ,而不是 long

Next, as @Eran pointed out (again), (int) -2147483648 / (int) -1 also does not fit int but the result is nevertheless int, not long.

推荐答案

主要原因是机器通常只添加其原生整数类型(和浮点数)的指令。这就是为什么对于许多语言,算术表达式中使用最少的类型是 int (通常是以某种方式对应于基本机器整数类型的类型)。

The main reason is that machines usually have only add instructions for their native integer type (and floats). This is why for many languages the least used type in an arithmetic expression is int (usually the type that correspond in some way to the basic machine integer type).

例如,i386规范说:

For example, i386 spec says:


ADD执行两个操作数的整数加法( DEST和SRC)。
添加的结果分配给第一个操作数(DEST),
并相应地设置标志。当一个立即字节被添加到
a word或doubleword操作数时,立即值被符号扩展为
字或双字操作数的大小。

ADD performs an integer addition of the two operands (DEST and SRC). The result of the addition is assigned to the first operand (DEST), and the flags are set accordingly. When an immediate byte is added to a word or doubleword operand, the immediate value is sign-extended to the size of the word or doubleword operand.

这意味着内部任何字节值都会扩展为整数(或类似值)。毕竟这是合理的,因为处理器是32/64位,然后执行这些大小的任何算术。如果有可能以字节为单位进行算术,这通常不被认为是有用的。

This means that internally any byte value is extended to an integer (or similar). After all this is reasonable as the processor is 32/64 bits and then perform any arithmetic in these sizes. If it could be possible to make arithmetic in bytes this is generally not considered as useful.

JVM规范说(对于加法)你有: iadd ladd fadd dadd 。这只是反映了底层机器通常表现如此的事实。任何其他选择都是可能的,可能是性能下降的代价。

The JVM specs says that (for addition) you have : iadd, ladd, fadd, dadd. This just reflect the fact that underlying machines usually behave such. Any other choice could have been possible, probably at the price of performance degradation.

这篇关于为什么字节和短分区在Java中导致int?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆