出于某种难以解释的原因,byte
原语类型是用Java语言签名的。这意味着有效值是-128..127,而不是通常0..255范围,表示字节中的8个有效位(没有符号位)。
这意味着所有字节操作代码通常执行整数计算,并最终屏蔽最后8位。
我想知道,在现实生活中,有没有什么场景可以让Java byte
原语类型完美匹配,或者它只是一个完全无用的设计决策?
编辑:唯一的实际用例是本机代码的单字节占位符。换句话说,不能在Java代码中作为一个字节来操作。
编辑:我现在已经看到了一个内部紧密循环需要除以7(数字0..32)的地方,这样就可以用字节作为数据类型来完成查找表,这样考虑到L1缓存的使用情况,就可以保持较低的内存使用率。这不是指签名/未签名,而是实际使用的情况。
发布于 2011-08-01 05:34:45
Josh Bloch最近mentioned in a presentation说这是语言中的错误之一。
我认为这背后的原因是byte
没有无符号的数字类型,java应该遵守这一规则。(注意:char
是无符号的,但不代表数字)
至于这个特殊的问题:我想不出任何例子。即使有示例,它们也会比0..255的示例更少,并且它们可以使用掩码(而不是大多数)来实现。
发布于 2011-08-01 15:01:33
byte, short, char
类型大多是无用的,除非用在数组中以节省空间。
无论是Java还是JVM都没有对它们的真正支持。几乎所有对它们的操作都会首先将它们提升到int
或long
。我们甚至不能写像这样的东西
short a=1, b=2;
a = a + b; // illegal
a = a << 1; // illegal
那么为什么还要费心在byte, short, char
类型上定义操作呢?
他们所做的一切都是偷偷地扩大转换,这会让程序员感到惊讶。
发布于 2011-08-01 11:19:50
令人惊讶的是,我上周才第一次在Java语言中使用byte
,所以我确实有一个用例(尽管不同寻常)。我正在写一个native Java function,它允许你在一个库中实现一个可以被Java调用的函数。Java类型需要转换为本机语言中的类型,在本例中为C
该函数需要接受一个字节数组,但是(当时完全忘记了byte
类型)我让它接受一个char[]
。Java为C函数生成的签名将该参数的类型指定为jcharArray
,可以将其转换为一堆jchar
,在jni.h
中将其类型定义为unsigned short
。当然,这并不是相同的大小--它是2个字节而不是1个字节。这会导致底层代码出现各种问题。生成Java类型的byte[]
生成jbyteArray
,并将Linux上的jbyte
类型定义为大小合适的signed char
https://stackoverflow.com/questions/6892444
复制相似问题