signed vs unsigned

[Gavin Deane]

Gavin Deane wrote:

Personally, I do not accept that argument for unsigned as documentation
to mean "negative values make no sense here". The variable name (age,
buffer_size, radius) serves that purpose.

<snip>

Hmmm.... Not sure why I'd want an integer, signed or otherwise, for a
radius. That would be a floating point type. Replace that with a more
sensible quantity - number of clients connected to the server, or
number of pigs on the farm or something.

Gavin Deane

 

[Neil Cerutti]

* Neil Cerutti:

I don't disagree with your viewpoint regarding using or not using
unsigned whenever possible; I think both are valid viewpoints, and
as with indentation the main thing is to be consistent in one's
choices.

However, I disagree with your reason!

With the unsigned argument a validity test might go like

assert( age < 200 ); // unsigned validity test.

That will help when the domain doesn't include all positive
representable integers, yes. You assumed a domain restriction that was
not in evidence. ;-)

With a signed argument the test might go like

assert( age >= 0 ); // signed validity test.
assert( age < 200 ); // more signed validity test.

I much prefer your second example, but perhaps that's a matter of
taste. Moreover, I don't want or need to learn the rules for unsigned
arithmetic if I only use them for their bit-values.

Now, first of all that demonstrates the "impossible to detect" is
simply incorrect, and second, in my view it demonstrates a slight
superiority for unsigned in this particular case, with respect to
validity testing.

Yes, I should have been more specific.

 

[Neil Cerutti]

These are often situations where you are unable to check validity
without domain specific knowledge - I don't see how signed unsigned
vary in that regard.

Because a signed negative value will be silently converted to a
positive unsigned value. I suppose this works both ways, though. I
can't prevent someone from passing a positive unsigned value to my
signed function, yielding the same problem in the mirror.

 

[Bob Hairgrove]

Surely overflow and underflow are a problem with both signed and unsigned?

They are a problem with signed (undefined or non-portable behavior),
but behavior with unsigned is well-defined by the standard (values
wrap). There is never any true overflow with unsigned integral values.

 

[Ben Pope]

They are a problem with signed (undefined or non-portable behavior),
but behavior with unsigned is well-defined by the standard (values
wrap). There is never any true overflow with unsigned integral values.

I guess that depends on your definition of overflow, in the context
provided I would class the following as overflow (on a platform with 8
bit char):

#include <iostream>

int main() {
unsigned char val = 128;
val *= 2; // overflow
std::cout << static_cast<unsigned int>(val) << "\n";
val = 0;
val -= 1; // underflow?
std::cout << static_cast<unsigned int>(val);
}

The behaviour may well be defined, but but I would call it overflow,
nonetheless.

I'm not sure if underflow is the correct term for the second "problem",
but that's what I call it.

Ben Pope

 

[Bo Persson]

Because a signed negative value will be silently converted to a
positive unsigned value. I suppose this works both ways, though. I
can't prevent someone from passing a positive unsigned value to my
signed function, yielding the same problem in the mirror.

So the real problem is mixing signed and unsigned values.

One solution, recommended elsewhere in this thread, is to just use one
kind. Probably signed then.


Bo Persson

 

[Bo Persson]

I guess that depends on your definition of overflow

In this context the difference is that with unsigned values you get a
known (but possibly useless) result. With signed artihmetic, you get
the dreaded "undefined behavior" - making your entire program formally
unusable.


Bo Persson