恕我直言，原因是他们太懒了，没有去实施/纠正这个错误。 暗示C/ c++程序员不理解unsigned，结构，联合，位标志…太荒谬了。

如果你正在和一个基本的/bash/java程序员交谈，即将开始用C语言编程，没有任何真正的语言知识，或者你只是在说你自己的想法。；）

当你每天处理文件或硬件的格式时，你会开始质疑，他们到底在想什么。

一个很好的例子是尝试使用无符号字节作为自旋转循环。 对于那些不理解最后一句话的人，你究竟是如何称自己为程序员的。

DC

我能想到一个不幸的副作用。在java嵌入式数据库中，使用32位id字段可以拥有的id数量是2^31，而不是2^32(~ 20亿，而不是~ 40亿)。

作为处理过无符号算术的人，我可以向您保证，在Java中确实没有必要使用无符号数字。

以C语言为例。让我们这样写:

unsigned int num = -7;
printf("%d", num);

你能猜到上面印的是什么吗?

-7

哇!无符号整数是负的!完全正确。没有真正的正整数。无符号整数只是一个n字节(取决于C语言中的体系结构)的值，它不为符号分配MSB。它不检查分配或读取的数字的实际符号。

这是对高斯林和其他人的采访，关于简单:

Gosling: For me as a language designer, which I don't really count myself as these days, what "simple" really ended up meaning was could I expect J. Random Developer to hold the spec in his head. That definition says that, for instance, Java isn't -- and in fact a lot of these languages end up with a lot of corner cases, things that nobody really understands. Quiz any C developer about unsigned, and pretty soon you discover that almost no C developers actually understand what goes on with unsigned, what unsigned arithmetic is. Things like that made C complex. The language part of Java is, I think, pretty simple. The libraries you have to look up.

http://skeletoncoder.blogspot.com/2006/09/java-tutorials-why-no-unsigned.html

这个家伙说，因为C标准定义了包含无符号整型和有符号整型的操作被视为无符号整型。这可能导致负符号整数滚动到一个大的无符号整数，可能会导致错误。

I once took a C++ course with someone on the C++ standards committee who implied that Java made the right decision to avoid having unsigned integers because (1) most programs that use unsigned integers can do just as well with signed integers and this is more natural in terms of how people think, and (2) using unsigned integers results in lots easy to create but difficult to debug issues such as integer arithmetic overflow and losing significant bits when converting between signed and unsigned types. If you mistakenly subtract 1 from 0 using signed integers it often more quickly causes your program to crash and makes it easier to find the bug than if it wraps around to 2^32 - 1, and compilers and static analysis tools and runtime checks have to assume you know what you're doing since you chose to use unsigned arithmetic. Also, negative numbers like -1 can often represent something useful, like a field being ignored/defaulted/unset while if you were using unsigned you'd have to reserve a special value like 2^32 - 1 or something similar.

Long ago, when memory was limited and processors did not automatically operate on 64 bits at once, every bit counted a lot more, so having signed vs unsigned bytes or shorts actually mattered a lot more often and was obviously the right design decision. Today just using a signed int is more than sufficient in almost all regular programming cases, and if your program really needs to use values bigger than 2^31 - 1, you often just want a long anyway. Once you're into the territory of using longs, it's even harder to come up with a reason why you really can't get by with 2^63 - 1 positive integers. Whenever we go to 128 bit processors it'll be even less of an issue.