Java 的短跨度为 -32768 (=0x8000),但为什么我们必须显式地将 0x8000 转换为短呢?

标签 java

根据以下信息,

enter image description here

enter image description here

我们知道 Java 的 short 范围是从 -32768 (=0x8000)32767 (=0x7FFF) 并且转换是可选的。我不明白的是,为什么我们必须将 0x8000 转换为 short 显式

public static void main(String[] args)
{        
    short x;
    x = (short) 0x8000;
    // x = 0x8000; // have to cast 0x8000 to short
    System.out.println(x);
}

我在 Windows 上使用 NetBeans。

最佳答案

0x8000 首先被解释为值为 32768 的整数,然后 Java 尝试将其转换为短整型,但它无法执行此操作,因为 32768 不适合短裤。

请注意,仅使用 32768 也能得到相同的结果:

short x = (short)32768;
System.out.println(x); // -32768

再举一个例子,考虑这行代码:

short x = 0xffff8000;
System.out.println(x); // -32768

这里不需要强制转换,因为0xffff8000是整数-32768,并且适合short。

但不要问我为什么他们决定让事情以这种方式工作(这可能只是为了让编译器保持简单)。

<小时/>

我在 JLS 中找到的唯一适用的摘录来自 5.2. Assignment Contexts : ( 3.10.1. Integer Literals 也相关)(但我肯定会错过相关部分)

In addition, if the expression is a constant expression (§15.28) of type byte, short, char, or int:

  • A narrowing primitive conversion may be used if the type of the variable is byte, short, or char, and the value of the constant expression is representable in the type of the variable

尽管在我看来,这确实对这里的预期行为留下了一些含糊之处。

关于Java 的短跨度为 -32768 (=0x8000),但为什么我们必须显式地将 0x8000 转换为短呢?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/49340105/

相关文章:

java - JBoss AS 5.1 上的 EJB3 注入(inject)失败错误 : ClassLoaders of value and target are not equal

java - Worldwind SurfaceImage 深度/批量拣选

java - EditText 上的 setText 无法正常工作

java - Tomcat 6 和 Tomcat 8 中 Java 1.8 的内存分配行为

java - 匹配两个很长容器中的两个 ID 的有效方法

java - Java中如何仅将特定版本的文件上传到GCS?

java - 理解装饰器设计模式

java - 改进mysql JDBC插入调用

java - 输入数据未存储在数据库中 - 为什么?

java - 使用 Java 进行硬盘基准测试,获得异常快的结果