signed vs unsigned

[Alf P. Steinbach]

Re: signed vs unsigned

* roberts.noah@gm ail.com:[color=blue]
> Alf P. Steinbach wrote:[color=green]
>> * Neil Cerutti:[color=darkred]
>>> On 2006-02-21, Tomás <NULL@NULL.NULL > wrote:
>>>> My first rule is to write "const" wherever I can.
>>>> (except for return types).
>>>>
>>>> My second rule is to write "unsigned" wherever I can.
>>> I don't agree with that rule.
>>>
>>>> Thus I'll write:
>>>>
>>>> unsigned GetDogAge(unsig ned const age)
>>>> {
>>>> return age * 7;
>>>> }
>>> What do you expect to happen if a client passes in an negative int?
>>>
>>> The argument is not in the domain, yet the error has been rendered
>>> impossible to detect or recover from.[/color]
>> 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.
>>
>> With a signed argument the test might go like
>>
>> assert( age >= 0 ); // signed validity test.
>> assert( age < 200 ); // more signed validity test.
>>
>> 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.[/color]
>
> I believe he is talking about something like this:
>[/color]
[snip][color=blue]
> int t = -5;
> unsigned int x = GetDogAge(t);[/color]

Yes, that would be caught by the validity test for unsigned formal arg,

assert( age < 200 );

Cheers,

- Alf


--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[wkaras@yahoo.com]

Re: signed vs unsigned

LuB wrote:[color=blue]
> This isn't a C++ question per se ... but rather, I'm posting this bcs I
> want the answer from a C++ language perspective. Hope that makes sense.
>
> I was reading Peter van der Linden's "Expert C Programming: Deep C
> Secrets" and came across the following statement:
>
> "Avoid unnecessary complexity by minimizing your use of unsigned types.
> Specifically, don't use an unsigned type to represent a quantity just
> because it will never be negative (e.g., "age" or "national_debt" )."
>
> Admittedly, I minimize comments in my code. I use them when necessary
> but try to limit them to one or two lines. I just don't like their
> aesthetic affect in the source. I find the code much harder to read
> littered with paragraphs of explanations.
>
> I find the code easier to read when broken up with appropriate newlines
> and small, short comments acting as headings.
>
> So - that effectually means that I try my darndest to write
> self-describing code. Shorter functions, self-explanatory names for
> functions and variable names, etc. Sometimes exceessive commenting is
> necessary, but as a whole, I tend to avoid it.
>
> I'm really enjoying Peter's book, but I find this comment hard to
> swallow considering that if an age or array index can never be negative
> - I would want to illustrate that with an apporpriate choice of type -
> namely, unsigned int.
>
> Am I in the minority here? Is my predilection considered poor style?
>
> I guess, from the compiler's standpoint ... using int everywhere is
> more portable ... since comparison's against unsigned int can vary
> between K&R and ANSI C.
>
> I'm not incurring some type of performance penalty for such decisions
> am I?
>
> Thanks in advance,
>
> -Luther[/color]

It's like driving on the left or driving on the right. It's basically
an
arbitrary choice (now that we drive cars), it's just good if everyone
makes the same arbitrary choice. That is if there's more than
just you on the road, which is analagous to maintaining
existing code or heavily using libraries written by others.

Many compilers generate (to me helpful) warnings if you do a[color=blue]
>, <, <=, >= comparison between a signed and unsigned.[/color]
Many also generate (to me useless) warnings if you do a
== or != comparison between a signed and unsigned. So,
you can end up with alot of static_casts to get rid of the
warnings.

For some reason, if an unsigned type is used in an expression
where it has to be implicitly converted to a larger type, it
will be converted to a signed larger type. As far as I can
see, this rule has no practical effect, other than to give
some compilers an excuse to generate unnecessary
warnings. (I guess it could change the results when
using bitwise ops on variables of different sizes, which
to me is a bad idea anyway.) So, that's one reason to prefer
signed. But, like you, I prefer to use unsigned for variables that
should always be nonnegative, to make the intent clear.

[Ben Pope]

Re: signed vs unsigned

Daniel T. wrote:[color=blue]
> In article <1140542925.375 975.294960@f14g 2000cwb.googleg roups.com>,
> roberts.noah@gm ail.com wrote:
>[color=green]
>> The great thing about unsigned is if the value can't be negative and
>> you use signed then you always have to check it. Simply defining the
>> type as unsigned gets rid of all that as well as documenting your
>> domain.[/color]
>
> And the bad thing about unsigned is that if code would otherwise make
> the value negative, you can't check it. IE[/color]

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

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.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

[Gavin Deane]

Re: signed vs unsigned


LuB wrote:[color=blue]
> This isn't a C++ question per se ... but rather, I'm posting this bcs I
> want the answer from a C++ language perspective. Hope that makes sense.
>
> I was reading Peter van der Linden's "Expert C Programming: Deep C
> Secrets" and came across the following statement:
>
> "Avoid unnecessary complexity by minimizing your use of unsigned types.
> Specifically, don't use an unsigned type to represent a quantity just
> because it will never be negative (e.g., "age" or "national_debt" )."
>
> Admittedly, I minimize comments in my code. I use them when necessary
> but try to limit them to one or two lines. I just don't like their
> aesthetic affect in the source. I find the code much harder to read
> littered with paragraphs of explanations.
>
> I find the code easier to read when broken up with appropriate newlines
> and small, short comments acting as headings.
>
> So - that effectually means that I try my darndest to write
> self-describing code. Shorter functions, self-explanatory names for
> functions and variable names, etc. Sometimes exceessive commenting is
> necessary, but as a whole, I tend to avoid it.[/color]

Self-explanatory names are good.
[color=blue]
> I'm really enjoying Peter's book, but I find this comment hard to
> swallow considering that if an age or array index can never be negative
> - I would want to illustrate that with an apporpriate choice of type -
> namely, unsigned int.[/color]

Why would you want to illustrate it with an appropriate choice of type?
I would want to illustrate it with a self-explanatory name.
[color=blue]
> Am I in the minority here? Is my predilection considered poor style?
>
> I guess, from the compiler's standpoint ... using int everywhere is
> more portable ... since comparison's against unsigned int can vary
> between K&R and ANSI C.
>
> I'm not incurring some type of performance penalty for such decisions
> am I?[/color]

This question comes up regularly. Search the history of the newsgroup
and you will find plenty of discussion. But I am slightly surprised to
see this thread get to nearly 20 posts (as far as I can see so far)
without anyone mentioning the subtraction issue.

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. Comparison with const is not
valid. const is useful because it is enforced by the compiler. unsigned
is not enforced. -1 years does not make sense for age, but neither does
4294967295 years. At best, using unsigned has only documented one end
of your range. And since the variable name has already achieved that,
you haven't gained anything.

But that's not the only reason I don't use unsigned for these sort of
quantities. In general, subtracting one person's age from another in
the real world yields a signed result but in C++ subtracting one
unsigned quantity from another yields an unsigned result.

<quote Kaz Kylheku (in post number 28 as I write this)>

http://groups.google.co.uk/group/comp.lang.c++/browse_frm/thread/6c639e720d5a58a1/0c236f41f9de66f8?q=%22Thus+code+like%22&rnum=1#0c236f41f9de66f8

Thus code like if (buffer_space - requested_paylo ad > header_size)
is broken if unsigned integers are used, and there was no prior check
that the requested_paylo ad isn't larger than the buffer.

</quote>

Both signed and unsigned arithmetic in C++ behave just like real world
integer arithmetic until you reach the minimum and maximum values for
those types. The difference is that for signed, the correlation between
the real world and C++ breaks down at + or - a very big number, whereas
for unsigned, the correlation between the real world and C++ breaks
down at zero and a (different) very big number.

In other words, if I use unsigned, I am very close to the edge of the
domain in which C++ arithmetic corresponds to the real world. If I use
signed, I am comfortably in the middle of that domain and the
extremities where I have to start coding for special cases are far, far
away from any number that I am likely to ever want to use for an age or
a length or a size, or I am likely to ever end up with by doing
arithmetic with those quantities.

Gavin Deane

[Ben Pope]

Re: signed vs unsigned

Gavin Deane wrote:[color=blue]
>
> But that's not the only reason I don't use unsigned for these sort of
> quantities. In general, subtracting one person's age from another in
> the real world yields a signed result but in C++ subtracting one
> unsigned quantity from another yields an unsigned result.
>
> <quote Kaz Kylheku (in post number 28 as I write this)>
> http://groups.google.co.uk/group/com...236f41f9de66f8
>
> Thus code like if (buffer_space - requested_paylo ad > header_size)
> is broken if unsigned integers are used, and there was no prior check
> that the requested_paylo ad isn't larger than the buffer.
>
> </quote>[/color]

That's a very good point.
[color=blue]
> Both signed and unsigned arithmetic in C++ behave just like real world
> integer arithmetic until you reach the minimum and maximum values for
> those types. The difference is that for signed, the correlation between
> the real world and C++ breaks down at + or - a very big number, whereas
> for unsigned, the correlation between the real world and C++ breaks
> down at zero and a (different) very big number.
>
> In other words, if I use unsigned, I am very close to the edge of the
> domain in which C++ arithmetic corresponds to the real world. If I use
> signed, I am comfortably in the middle of that domain and the
> extremities where I have to start coding for special cases are far, far
> away from any number that I am likely to ever want to use for an age or
> a length or a size, or I am likely to ever end up with by doing
> arithmetic with those quantities.[/color]

In an ideal world, we would probably all do range checking more often
than we do.

I always say you make your own luck, with signed types you're more lucky!

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

[Gavin Deane]

Re: signed vs unsigned


Gavin Deane wrote:

<snip>
[color=blue]
> 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.[/color]

<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]

Re: signed vs unsigned

On 2006-02-21, Alf P. Steinbach <alfps@start.no > wrote:[color=blue]
> * Neil Cerutti:[color=green]
>> On 2006-02-21, Tomás <NULL@NULL.NULL > wrote:[color=darkred]
>>> My first rule is to write "const" wherever I can.
>>> (except for return types).
>>>
>>> My second rule is to write "unsigned" wherever I can.[/color]
>>
>> I don't agree with that rule.
>>[color=darkred]
>>> Thus I'll write:
>>>
>>> unsigned GetDogAge(unsig ned const age)
>>> {
>>> return age * 7;
>>> }[/color]
>>
>> What do you expect to happen if a client passes in an negative int?
>>
>> The argument is not in the domain, yet the error has been rendered
>> impossible to detect or recover from.[/color]
>
> 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.[/color]

That will help when the domain doesn't include all positive
representable integers, yes. You assumed a domain restriction that was
not in evidence. ;-)
[color=blue]
> With a signed argument the test might go like
>
> assert( age >= 0 ); // signed validity test.
> assert( age < 200 ); // more signed validity test.[/color]

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.
[color=blue]
> 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.[/color]

Yes, I should have been more specific.

--
Neil Cerutti

[Neil Cerutti]

Re: signed vs unsigned

On 2006-02-22, Ben Pope <benpope81_REMO VE_@gmail.com> wrote:[color=blue]
> Daniel T. wrote:[color=green]
>> In article <1140542925.375 975.294960@f14g 2000cwb.googleg roups.com>,
>> roberts.noah@gm ail.com wrote:
>>[color=darkred]
>>> The great thing about unsigned is if the value can't be negative
>>> and you use signed then you always have to check it. Simply
>>> defining the type as unsigned gets rid of all that as well as
>>> documenting your domain. >> >> And the bad thing about unsigned
>>> is that if code would otherwise make >> the value negative, you
>>> can't check it. IE > > Surely overflow and underflow are a problem
>>> with both signed and unsigned?[/color][/color]
>
> 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.[/color]

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.

--
Neil Cerutti

[Bob Hairgrove]

Re: signed vs unsigned

On Wed, 22 Feb 2006 10:34:20 +0000, Ben Pope
<benpope81_REMO VE_@gmail.com> wrote:
[color=blue]
>Daniel T. wrote:[color=green]
>> In article <1140542925.375 975.294960@f14g 2000cwb.googleg roups.com>,
>> roberts.noah@gm ail.com wrote:
>>[color=darkred]
>>> The great thing about unsigned is if the value can't be negative and
>>> you use signed then you always have to check it. Simply defining the
>>> type as unsigned gets rid of all that as well as documenting your
>>> domain.[/color]
>>
>> And the bad thing about unsigned is that if code would otherwise make
>> the value negative, you can't check it. IE[/color]
>
>Surely overflow and underflow are a problem with both signed and unsigned?[/color]

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.
[color=blue]
>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.
>
>Ben Pope[/color]

--
Bob Hairgrove
NoSpamPlease@Ho me.com

[Ben Pope]

Re: signed vs unsigned

Bob Hairgrove wrote:[color=blue]
> On Wed, 22 Feb 2006 10:34:20 +0000, Ben Pope
> <benpope81_REMO VE_@gmail.com> wrote:
>[color=green]
>> Surely overflow and underflow are a problem with both signed and unsigned?[/color]
>
> 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.[/color]

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<uns igned int>(val) << "\n";
val = 0;
val -= 1; // underflow?
std::cout << static_cast<uns igned 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
--
I'm not just a number. To many, I'm known as a string...

[Bo Persson]

Re: signed vs unsigned


"Neil Cerutti" <leadvoice@emai l.com> skrev i meddelandet
news:slrndvonkv .b4.leadvoice@F IAD06.norwich.e du...[color=blue]
> On 2006-02-22, Ben Pope <benpope81_REMO VE_@gmail.com> wrote:[color=green]
>> Daniel T. wrote:[color=darkred]
>>> In article
>>> <1140542925.375 975.294960@f14g 2000cwb.googleg roups.com>,
>>> roberts.noah@gm ail.com wrote:
>>>
>>>> The great thing about unsigned is if the value can't be negative
>>>> and you use signed then you always have to check it. Simply
>>>> defining the type as unsigned gets rid of all that as well as
>>>> documenting your domain. >> >> And the bad thing about unsigned
>>>> is that if code would otherwise make >> the value negative, you
>>>> can't check it. IE > > Surely overflow and underflow are a
>>>> problem
>>>> with both signed and unsigned?[/color]
>>
>> 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.[/color]
>
> 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.[/color]

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]

Re: signed vs unsigned


"Ben Pope" <benpope81_REMO VE_@gmail.com> skrev i meddelandet
news:43fca837$0 $8258$6d36acad@ taz.nntpserver. com...[color=blue]
> Bob Hairgrove wrote:[color=green]
>> On Wed, 22 Feb 2006 10:34:20 +0000, Ben Pope
>> <benpope81_REMO VE_@gmail.com> wrote:
>>[color=darkred]
>>> Surely overflow and underflow are a problem with both signed and
>>> unsigned?[/color]
>>
>> 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.[/color]
>
> I guess that depends on your definition of overflow[/color]

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