Steven Schveighoffer wrote:
On Mon, 15 Feb 2010 17:21:09 -0500, Walter Bright <newshou...@digitalmars.com> wrote:

Steven Schveighoffer wrote:
are there any good cases besides this that Walter has? And even if there are, we are not talking about silently mis-interpreting it. There is precedent for making valid C code an error because it is error prone.


Here's where I'm coming from with this. The problem is that CPU integers are 2's complement and a fixed number of bits. We'd like to pretend they work just like whole numbers we learned about in 2nd grade arithmetic. But they don't, and we can't fix it so they do. I think it's ultimately fruitless to try and make them behave other than what they are: 2's complement fixed arrays of bits.

So, we wind up with oddities like overflow, wrap-around, -int.min==int.min. Heck, we *rely* on these oddities (subtraction depends on wrap-around). Sometimes, we pretend these bit values are signed, sometimes unsigned, and we mix together those notions in the same expression.

One further thing I'll say on this:

signed computer math makes a lot of sense to people because the limits are so large. For instance, -2 billion to 2 billion. It seems logical that a computer can't just keep coming up with new bits to represent numbers, but it seems so far off that an integer will wrap at 2 billion. But unsigned math has a much more familiar boundary -- zero. Numbers are far more likely to be near zero than they are near 2 billion or -2 billion. Applying a negation operator to an unsigned value almost *guarantees* wrapping past that boundary. 99% of the time, when I apply a negative sign to a number, I want the negative equivalent of that number. I don't want some large bizarre value that has no relation to that number, despite what the computer thinks is sane. I'd look at applying a negation operator to an unsigned int with as much scrutiny as I'd look at multiplying an integer by 1_000_000_000. It's almost guaranteed to go out of bounds, why are you doing it?

Bringing up -int.min == int.min is exactly my point. For integers, there is one value that the negation operator doesn't work as expected. For unsigned integers, there is only one number that *does* work as expected -- zero. All others either don't work as expected, or rely on the computer behaving strangely (if it is indeed expected). To make such rare purposeful uses more explicit does not lower the quality of code or the ease of use.

Well said.

-Lars

Reply via email to