为什么Java不支持无符号整数?
在我看来,这是一个奇怪的遗漏,因为它们允许人们编写不太可能在意外的大输入上产生溢出的代码。
此外,使用无符号整数可以是一种自我文档的形式,因为它们表明无符号整型所要保存的值永远不应该是负数。
最后,在某些情况下,无符号整数对于某些运算(如除法)更有效。
包含这些的缺点是什么?
为什么Java不支持无符号整数?
在我看来,这是一个奇怪的遗漏,因为它们允许人们编写不太可能在意外的大输入上产生溢出的代码。
此外,使用无符号整数可以是一种自我文档的形式,因为它们表明无符号整型所要保存的值永远不应该是负数。
最后,在某些情况下,无符号整数对于某些运算(如除法)更有效。
包含这些的缺点是什么?
当前回答
作为处理过无符号算术的人,我可以向您保证,在Java中确实没有必要使用无符号数字。
以C语言为例。让我们这样写:
unsigned int num = -7;
printf("%d", num);
你能猜到上面印的是什么吗?
-7
哇!无符号整数是负的!完全正确。没有真正的正整数。无符号整数只是一个n字节(取决于C语言中的体系结构)的值,它不为符号分配MSB。它不检查分配或读取的数字的实际符号。
其他回答
一旦有符号整型和无符号整型混合在表达式中,事情就开始变得混乱,你可能会丢失信息。将Java限制为有符号int型只能真正解决问题。我很高兴我不必担心整个有符号/无符号的问题,尽管我有时会错过字节中的第8位。
恕我直言,原因是他们太懒了,没有去实施/纠正这个错误。 暗示C/ c++程序员不理解unsigned,结构,联合,位标志…太荒谬了。
如果你正在和一个基本的/bash/java程序员交谈,即将开始用C语言编程,没有任何真正的语言知识,或者你只是在说你自己的想法。;)
当你每天处理文件或硬件的格式时,你会开始质疑,他们到底在想什么。
一个很好的例子是尝试使用无符号字节作为自旋转循环。 对于那些不理解最后一句话的人,你究竟是如何称自己为程序员的。
DC
我认为Java本身就很好,添加unsigned会使它变得复杂而没有太多好处。 即使使用简化的整数模型,大多数Java程序员也不知道基本的数字类型是如何行为的——只要阅读《Java Puzzlers》一书,就能了解您可能持有的误解。
至于实用的建议:
如果你的值是任意大小,不适合int,使用long。 如果它们不适合长期使用BigInteger。 只有在需要节省空间时,才对数组使用较小的类型。 如果你正好需要64/32/16/8位,使用long/int/short/byte,不要担心符号位,除法、比较、右移和强制转换除外。
另请参阅关于“将一个随机数生成器从C移植到Java”的回答。
Java确实有unsigned类型,或者至少有一个:char是一个unsigned short类型。所以不管高斯林找什么借口,他都不知道为什么没有其他无符号类型。
还有短型:短型一直被用于多媒体。原因是您可以在一个32位无符号长函数中拟合2个样本,并向量化许多操作。8位数据和无符号字节也是如此。你可以在一个寄存器中放入4或8个样本进行向量化。
因为无符号类型是纯粹的邪恶。
事实上,在C语言中unsigned int生成unsigned更是邪恶的。
下面是一个让我不止一次头疼的问题的快照:
// We have odd positive number of rays,
// consecutive ones at angle delta from each other.
assert( rays.size() > 0 && rays.size() % 2 == 1 );
// Get a set of ray at delta angle between them.
for( size_t n = 0; n < rays.size(); ++n )
{
// Compute the angle between nth ray and the middle one.
// The index of the middle one is (rays.size() - 1) / 2,
// the rays are evenly spaced at angle delta, therefore
// the magnitude of the angle between nth ray and the
// middle one is:
double angle = delta * fabs( n - (rays.size() - 1) / 2 );
// Do something else ...
}
你注意到这个bug了吗?我承认我是在使用调试器之后才看到它的。
由于n是无符号类型size_t,整个表达式n - (ray .size() - 1) / 2的计算结果为无符号。该表达式旨在表示从中间那条线开始的第n条射线的符号位置:从左边那条线开始的第1条射线的位置为-1,右边那条线的位置为+1,等等。在取abs值并乘以角之后,我将得到第n条射线与中间那条射线之间的夹角。
不幸的是,对我来说,上面的表达式包含了邪恶的unsigned,它的计算结果不是-1,而是2^32-1。随后转换为双密封的bug。
由于滥用无符号算术而导致的一两个错误之后,人们不得不开始考虑获得的额外比特是否值得额外的麻烦。我正在尽可能地避免在算术中使用无符号类型,尽管仍然将它用于非算术操作,如二进制掩码。