«

Hello,

Often I happen to be dealing with nonnegative integers and since I know I won't
need negative numbers here I declare them as unsigned simply to make the program
somewhat clearer. Effectively, though, signed integers would often work too since
unless I am doing some modular arithmetic modulo the word length then I almost
never need to use the high bit since the integers I deal with are usually not
that large, and I would assume this is true of most programs in general.

So, the question is, when you know an integer is not going to be negative, is that
good enough reason to declare it as unsigned, or does doing so somewhat slow down
the computer (e.g. are signed addition, subtraction, etc... somewhat faster and
why would that be so?)?

Thanks,

Neil

Neil Zanella wrote:

> Hello,
>
> Often I happen to be dealing with nonnegative integers and since I know I
> won't need negative numbers here I declare them as unsigned simply to make
> the program somewhat clearer.

So do I.

> Effectively, though, signed integers would
> often work too since unless I am doing some modular arithmetic modulo the
> word length then I almost never need to use the high bit since the
> integers I deal with are usually not that large, and I would assume this
> is true of most programs in general.

Well, if your modulus happens to be 2 to the N, where N is the number of
value bits in the unsigned integer type, you're in luck.

But I presume you're talking about, say, day of week (modulo 7), month of
year (modulo 12), or perhaps (integral) angle in degrees (modulo 360). That
/sort/ of thing.

> So, the question is, when you know an integer is not going to be negative,
> is that good enough reason to declare it as unsigned,

IMHO, yes.

> or does doing so
> somewhat slow down the computer (e.g. are signed addition, subtraction,
> etc... somewhat faster and why would that be so?)?

The Standard doesn't require unsigned integer types to go slower than signed
integer types.

If you are sure you'll never overflow the maximum value for the type, feel
free to use signed if you wish. I prefer to use unsigneds.

--
Richard Heathfield :
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton

(Neil Zanella) wrote in
news: om:

> Often I happen to be dealing with nonnegative integers and since I know
> I won't need negative numbers here I declare them as unsigned simply to
> make the program somewhat clearer. Effectively, though, signed integers
> would often work too since unless I am doing some modular arithmetic
> modulo the word length then I almost never need to use the high bit
> since the integers I deal with are usually not that large, and I would
> assume this is true of most programs in general.
>
> So, the question is, when you know an integer is not going to be
> negative, is that good enough reason to declare it as unsigned, or does
> doing so somewhat slow down the computer (e.g. are signed addition,
> subtraction, etc... somewhat faster and why would that be so?)?

On small micros without sign-support hardware signed maybe slower, e.g.
the venerable 8051. However, unless you need instruction level determinism
I wouldn't worry about it. Make the vars. unsigned when the value is not
negative. For example, why would you ever need to express someone's age in
years as a signed value? Since we know better than to mix control with
data we wouldn't use a negative value for an error so I'd certainly expect
to see age declared as:

unsigned int ageInYears;

or

unsigned char ageInYears;

--
- Mark ->
--

In article < >,
(Neil Zanella) wrote:

> Hello,
>
> Often I happen to be dealing with nonnegative integers and since I know I
> won't
> need negative numbers here I declare them as unsigned simply to make the
> program
> somewhat clearer. Effectively, though, signed integers would often work too
> since
> unless I am doing some modular arithmetic modulo the word length then I
> almost
> never need to use the high bit since the integers I deal with are usually not
> that large, and I would assume this is true of most programs in general.
>
> So, the question is, when you know an integer is not going to be negative, is
> that
> good enough reason to declare it as unsigned, or does doing so somewhat slow
> down
> the computer (e.g. are signed addition, subtraction, etc... somewhat faster
> and
> why would that be so?)?

For signed integers, the C operators +, -, * produce exactly the same
results as the mathematical operators (as long as the results are not
too large). For unsigned integers, the C operators do some pretty weird
things. A trivial example: For which numbers is

x >= y - 1

true if x and y are both signed, both unsigned, one signed and the other
unsigned? For signed numbers, you are quite safe. Both unsigned, and
there is a strange special case for y = 0. One signed and the other
unsigned, and you have to study the C Standard.

It seems what you have are "positive" numbers. "unsigned" is something
completely different; unsigned numbers can behave in completely
unexpected ways. x - 1 is not one less than x in very common cases.

(And some people will be in for some nasty surprises if they switch to a
compiler where unsigned int and unsigned long have different sizes. )

(Neil Zanella) writes:
> Often I happen to be dealing with nonnegative integers and since I
> know I won't need negative numbers here I declare them as unsigned
> simply to make the program somewhat clearer. Effectively, though,
> signed integers would often work too since unless I am doing some
> modular arithmetic modulo the word length then I almost never need
> to use the high bit since the integers I deal with are usually not
> that large, and I would assume this is true of most programs in
> general.
>
> So, the question is, when you know an integer is not going to be
> negative, is that good enough reason to declare it as unsigned, or
> does doing so somewhat slow down the computer (e.g. are signed
> addition, subtraction, etc... somewhat faster and why would that be
> so?)?

There are some risks in using unsigned types. Consider:

int i;
for (i = 9; i >= 0; i --) { printf("%d\n", i); }

vs.

unsigned int u;
for (u = 9; u >= 0; u --) { printf("%u\n", u); }

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

On 5 Feb 2004 22:20:43 GMT, "Mark A. Odell" <>
wrote in comp.lang.c:

> (Neil Zanella) wrote in
> news: om:
>
> > Often I happen to be dealing with nonnegative integers and since I know
> > I won't need negative numbers here I declare them as unsigned simply to
> > make the program somewhat clearer. Effectively, though, signed integers
> > would often work too since unless I am doing some modular arithmetic
> > modulo the word length then I almost never need to use the high bit
> > since the integers I deal with are usually not that large, and I would
> > assume this is true of most programs in general.
> >
> > So, the question is, when you know an integer is not going to be
> > negative, is that good enough reason to declare it as unsigned, or does
> > doing so somewhat slow down the computer (e.g. are signed addition,
> > subtraction, etc... somewhat faster and why would that be so?)?
>
> On small micros without sign-support hardware signed maybe slower, e.g.
> the venerable 8051

[snip]

<somewhat off topic>
I beg your pardon, but an 8051 has a carry flag and can performed
signed arithmetic with the same speed as unsigned arithmetic.

There are a lot of reasons to look down one's nose and the brain-dead
little work-horse, but this is not one of them.
</somewhat off topic>

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

On 5 Feb 2004 13:18:31 -0800, (Neil Zanella) wrote
in comp.lang.c:

> Hello,
>
> Often I happen to be dealing with nonnegative integers and since I know I won't
> need negative numbers here I declare them as unsigned simply to make the program
> somewhat clearer. Effectively, though, signed integers would often work too since
> unless I am doing some modular arithmetic modulo the word length then I almost
> never need to use the high bit since the integers I deal with are usually not
> that large, and I would assume this is true of most programs in general.
>
> So, the question is, when you know an integer is not going to be negative, is that
> good enough reason to declare it as unsigned, or does doing so somewhat slow down
> the computer (e.g. are signed addition, subtraction, etc... somewhat faster and
> why would that be so?)?
>
> Thanks,
>
> Neil

Speed or efficiency of operation is no different between pure signed
or unsigned types on any architecture developed in the last quarter
century at least.

There are pros and cons to using unsigned types.

One of the biggest pros is simpler range checking in functions.
Suppose for example that you have a function that can be properly
called with a value between 0 and 10, and it is the function's job to
validate the argument and return an error code if it is out of range.
Now look at the two functions below:

int s_func(signed int x)
{
if ((x >= 0) && (x <= 10))
{
/* do stuff */
return OK;
}
else
{
return ERROR;
}
}

Now the unsigned version, the checking is simpler:

int u_func(unsigned int x)
{
if (x <= 10)
--------

The biggest con to using unsigned is that you have to know what can
happen when mixing with signed or you can be unpleasantly surprised.

unsigned int x = 12;

if (x > -1)
{
puts("Yippee!");
}
else
{
puts("Ouch!");
}

The code above will output "Ouch!".

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

Christian Bau <> writes:

> For signed integers, the C operators +, -, * produce exactly the same
> results as the mathematical operators (as long as the results are not
> too large).

ITYM as long as the absolute values of the results are not too large.

> For unsigned integers, the C operators do some pretty weird
> things. A trivial example: For which numbers is
>
> x >= y - 1
>
> true if x and y are both signed, both unsigned, one signed and the other
> unsigned? For signed numbers, you are quite safe. Both unsigned, and
> there is a strange special case for y = 0.

For signed ints, there is a strange special case for y = INT_MIN. With
unsigned integers, you have well-defined over/underflow semantics at
least, but as long as you stay within the range of the type, you are
safe with both signed and unsigned integers.

Martin

Keith Thompson <kst-> writes:

> There are some risks in using unsigned types. Consider:
>
> int i;
> for (i = 9; i >= 0; i --) { printf("%d\n", i); }
>
> vs.
>
> unsigned int u;
> for (u = 9; u >= 0; u --) { printf("%u\n", u); }

Some compilers can even warn you of comparisons which are always true.
The latter case can be rewritten as, for example,

unsigned int u;
for (u = 10; u-- > 0 { printf("%u\n", u); }

which uses unsigned integers and has the intended effect.

Martin

In article <bvvcvd$lt8$05$>,
Martin Dickopp <expires-2004-03-> wrote:

> Christian Bau <> writes:
>
> > For signed integers, the C operators +, -, * produce exactly the same
> > results as the mathematical operators (as long as the results are not
> > too large).
>
> ITYM as long as the absolute values of the results are not too large.
>
> > For unsigned integers, the C operators do some pretty weird
> > things. A trivial example: For which numbers is
> >
> > x >= y - 1
> >
> > true if x and y are both signed, both unsigned, one signed and the other
> > unsigned? For signed numbers, you are quite safe. Both unsigned, and
> > there is a strange special case for y = 0.
>
> For signed ints, there is a strange special case for y = INT_MIN. With
> unsigned integers, you have well-defined over/underflow semantics at
> least, but as long as you stay within the range of the type, you are
> safe with both signed and unsigned integers.

Which case happens more often, INT_MIN or 0?