There are also performance benefits of unsigned integer types: division, modulo and sometimes multiplication for them works slightly faster.
Almost Always Unsigned
71–80 of 103 posts
Re: Almost Always Unsigned
#72> The most typical argument against the use of unsigned integers is that it’s more error prone
Not only, most people don't know the rules even.
> 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.
Taken from http://www.gotw.ca/publications/c_family_interview.htm
Re: Almost Always Unsigned
#73Stroustrup recommends int over unsigned. Dijkstra recommends int over unsigned. Google coding guidelines recommend int over unsigned. Blogger recommends unsigned over int. Tough choice.
Gosling went one step further unsigned isn't even available, although nowadays there are helper classes for doing unsigned arithmetic.
Re: Almost Always Unsigned
#74As a Java developer I'm a bit sad that we don't have a choice :)
The reason is in this interview,
http://www.gotw.ca/publications/c_family_interview.htm
> 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.
You have the option in the standard library, all numeric classes have unsigned arithmetic methods.
And as we are finally getting value classes in Java (first integration steps), I expect someone will come up unsigned wrapper classes rather quickly, although it will be rather verbose without operator overloading.
Re: Almost Always Unsigned
#75As a Java developer I'm a bit sad that we don't have a choice :)
You can do stuff with unsigned values, it's just awkward. It most frequently comes up when serializing things.
Or talking to the hardware, or doing graphics stuff.
But it isn't the end of the world, a few helper methods and done with it.
Re: Almost Always Unsigned
#76I have a better solution: address the root cause of unsafe semantics by not using raw indexed for-loops, unless one absolutely needs an index, in which case one should generate it with std::views::enumerate. To reverse it, use std::views::enumerate | std::views::reverse. Ditto for languages with similar semantics. I almost never write a raw for-i loop any more, especially since 99% of the time I want to enumerate thr…
Loop counters really are not the problem. The problem is that even when using unsigned integers you often want to do 'signed math' on them (e.g. adding a negative amount, or you could have an expression made entirely of unsigned integers (like ((x - y) + z) where an intermediate result may become negative even when the end result is positive - and in languages with overflow check that may result in a panic).
A better rule of thumb is to always use signed integers, except for bit twiddling and modulo-math.
Especially with 64-bit integers it's really no longer an issue to lose one bit for the sign (63 bits ought to be enough for anybody heh).
Re: Almost Always Unsigned
#77 using int64 = int64_t;
using nat64 = uint64_t;
Or, if you must, the positive integers:
using pos64 = uint64_t;Re: Almost Always Unsigned
#78In a language that has arbitrary precision integers, you'd pretty much never want them unsigned, or even to have signed and unsigned flavors. Whether unsigned or signed is better is a matter that is a combination of personal opinion and the quirks of a given systems programming fixed integer language. The trade-off reasoning would be different, for instance, in a language that requires implementations to provide two'…
[dead]
Re: Almost Always Unsigned
#79I have a better solution: address the root cause of unsafe semantics by not using raw indexed for-loops, unless one absolutely needs an index, in which case one should generate it with std::views::enumerate. To reverse it, use std::views::enumerate | std::views::reverse. Ditto for languages with similar semantics. I almost never write a raw for-i loop any more, especially since 99% of the time I want to enumerate thr…
> I have a better solution: address the root cause of unsafe semantics by not using raw indexed for-loops, unless one absolutely needs an index, in which case one should generate it with std::views::enumerate.
That’s why Swift completely removed that kind of for loop (https://github.com/swiftlang/swift-evolution/blob/main/propo...)
> This stuff compiles to broadly the same assembly.
At the cost of requiring a more complex compiler. Also, C/C++ won’t find “broadly the same” sufficient. They’ll want to see the same performance.
Re: Almost Always Unsigned
#80A long time ago, I also thought one should use unsigned mostly but I am now in the opposite camp. Unsigned integers in C have semantics for modulo arithmetic. They are suitable if you need this, so for crypto, hashes, or if you only care about bits, etc. IMHO they should not be used for anything else. The reason is that it is very easy to screen for signed overflow bugs exactly because they have undefined behavior, just by turning on a sanitizer. It is also possible to transform overflow to safe traps at run-time where this is important. In contrast, finding unsigned wraparound bugs is extremely hard and can not be done automatically and preventing consequences of such bugs is difficult. Also any kind of index computation may have intermediate results that may be negative, so signed arithmetic is also generally more useful and far easier for people to understand and get right.