when to use uint? dis/advantages?

[Song Yun Zhao]

Hi,

Just wondering what are the dis/advantages of using uint vs int. When
would be the best time to use it?

Personally I don't use uint that much, but I like to optimize my code
and make it as effective as possible. So I feel that using an int where
only an uint is needed is a waste.

e.g. something like (int i = 0; i < 100; i++)
could probably better be written as (uint i = 0; i < 100; i++)
or maybe even better (unsigned short i = 0; i < 100; i++)

One big advantage of using uint is that if I have a function like

void foobar(uint i)
{
if (i >= 0) {
cout << "generate a warning, this is always true" << endl;
}
}

and calling foobar(-1) will generate a warning. This can help me iron
out some problems/bugs at compile time.

However using uint does require more work, for example when comparing an
uint to int will generate a warning, hence would require a static_cast.

Anyway, I want to know what other programmers are doing. I use Qt a lot
at work, and I don't see a lot of uint in Qt's code. Could this be for
portability reasons?

Anyway all comments are appricated. TIA.

Song

[Jonathan Turkanis]

Song Yun Zhao wrote:

Hi,

Just wondering what are the dis/advantages of using uint vs int.

What's uint?

Jonathan

[Song Yun Zhao]

Jonathan Turkanis wrote:

What's uint?

Jonathan

unsigned int

[Jonathan Turkanis]

Song Yun Zhao wrote:

Jonathan Turkanis wrote:

What's uint?

unsigned int

Or it could be:

typedef mounatin_range<uinta> uint;

Jonathan

[Song Yun Zhao]

Jonathan Turkanis wrote:

Or it could be:

typedef mounatin_range<uinta> uint;

Jonathan

what's ur point?

[Jonathan Turkanis]

Song Yun Zhao wrote:

Jonathan Turkanis wrote:

Or it could be:

typedef mounatin_range<uinta> uint;

Jonathan

what's ur point?

I meant to say mountain_range. Now is everything clear?

Jonathan

[rajkumar]

Hey

Lots of functions return 0 - N for okay and -1 for error conditions.
If you store these values in a unsigned int you will never be able to
detect these error conditions.

Also if somebody refactors you code later and changes

for ( unsigned int i = 0; u < 100 ; i++ )

to

for ( unsigned int i = 100 -1 ; i >= 0 ; --i )

you get an infinite loop
Raj

[Song Yun Zhao]

Jonathan Turkanis wrote:

I meant to say mountain_range. Now is everything clear?

not really, r u trying to say that uint is not a standard type?

Song

[Ioannis Vranos]

Song Yun Zhao wrote:

Hi,

Just wondering what are the dis/advantages of using uint vs int. When
would be the best time to use it?

In technical discussions we strive for accuracy. uint does not mean
anything in particular.

Personally I don't use uint that much, but I like to optimize my code
and make it as effective as possible. So I feel that using an int where
only an uint is needed is a waste.

e.g. something like (int i = 0; i < 100; i++)
could probably better be written as (uint i = 0; i < 100; i++)
or maybe even better (unsigned short i = 0; i < 100; i++)

One big advantage of using uint is that if I have a function like

void foobar(uint i)
{
if (i >= 0) {
cout << "generate a warning, this is always true" << endl;
}
}

and calling foobar(-1) will generate a warning. This can help me iron
out some problems/bugs at compile time.

assigning -1 to an unsigned integral type variable, assigns the maximum
value of its type to it.
However using uint does require more work, for example when comparing an
uint to int will generate a warning, hence would require a static_cast.

Anyway, I want to know what other programmers are doing. I use Qt a lot
at work, and I don't see a lot of uint in Qt's code. Could this be for
portability reasons?

Anyway all comments are appricated. TIA.

Use signed integral types when you need to use them for negative values
too. If you deal only with positive values and/or want to have more
positive value range at the same type size, use the unsigned types.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[shabbir]

uint and int will not make a slight of difference in todays speed of
computer and its almost obsolete.

it is there in C++ for a simple reason "Backward compatibility" and
will not make any help to you as far as my shallow knowledge goes.

[eed132]

I don't know of any reason why it would make a speed difference, but it
is not there just for backwards compatibility by any stretch of
imagination.

Remember that the types are different sizes. Have data that can range
up to, say, 4 billion but you can gurantee will be positive? You gotta
use an unsigned int.

[Howard]

"Song Yun Zhao" <mr************@yahoo.com.au> wrote in message
news:42********@news.alphalink.com.au...

Hi,

Just wondering what are the dis/advantages of using uint vs int. When
would be the best time to use it?

There is no such type as uint. You are free to typedef unsigned int as uint
(or your compiler vendor may have done so for you, in some header), but
otherwise it means nothing.

By the way, if you're just saying "uint" because it takes too long to write
"unsigned int", just like I see you writing "u r" instead of "you are", then
please refrain from doing that. We really need to stay technically accurate
here (as much as possible, anyway). Thanks.
Personally I don't use uint that much, but I like to optimize my code and
make it as effective as possible. So I feel that using an int where only
an uint is needed is a waste.

What is "wasted"?
e.g. something like (int i = 0; i < 100; i++)
could probably better be written as (uint i = 0; i < 100; i++)
or maybe even better (unsigned short i = 0; i < 100; i++)

Or even unsigned char! Your compiler may actually use whatever size is
appropriate to your platform, provided it behaves the same. Using unsigned
int just takes a little longer to write than int. It is not likely to
effect your performance at all.
One big advantage of using uint is that if I have a function like

void foobar(uint i)
{
if (i >= 0) {
cout << "generate a warning, this is always true" << endl;
}
}

and calling foobar(-1) will generate a warning. This can help me iron out
some problems/bugs at compile time.

Calling foobar(-1) will change the -1 to an unsigned int (assuming that uint
is the same as unsigned int), and will result in a very large positive
integer, which is obviously greater than 0. Also, the code above will issue
a warning no matter what you pass as the parameter, since an unsigned int is
_always_ zero or greater. I guess I'm just not sure I understand what your
point was. Do you actually have the code above somewhere?
However using uint does require more work, for example when comparing an
uint to int will generate a warning, hence would require a static_cast.

If you're comparing against a (signed) int, then you ought to use a (signed)
int to compare against, unless you can guarantee that the (signed) int will
never actually be negative. Using a static_cast is not a bad thing, if you
know that that's what you have to do. And this type of comparison is one of
the few places I'd use it. (Unless of course I could avoid it by using
matching types in the first place.)
Anyway, I want to know what other programmers are doing. I use Qt a lot at
work, and I don't see a lot of uint in Qt's code. Could this be for
portability reasons?

I use unsigned int (or char, or short, or long) where I think it's
appropriate. They pay me to think here, so I do. :-)

Seriously, if I know that the value in question will never be negative, I'm
likely to use unsigned, since it becomes apparent to those reading my code
that the value is intended to be positive or zero (and will always be so).
If the value _may_ be negative for any reason, then I _must_ use a signed
version. I'll admit that I sometimes write simple for loops without the
"unsigned" specifier, but that's really just laziness on my part, not a
conscious choice to use signed. (Oh, and sometimes I change my mind and add
or remove the unsigned specifier, as I develop my code and realize the other
parts I'm interacting with differ from my previous assumptions.)

One other point: I don't actually use int (or unsigned int) that much.
Mostly I use short, long or char (or the unsigned versions thereof). Those
give me more of an obvious indication of the range of values my variable is
going to take.

-Howard

[Julie]

ra******@hotmail.com wrote:

Hey

Lots of functions return 0 - N for okay and -1 for error conditions.
Indication of poor design: using a value to indicate both a value and an error
condition, should be separate variables or an exception.
If you store these values in a unsigned int you will never be able to
detect these error conditions.

Also if somebody refactors you code later and changes

for ( unsigned int i = 0; u < 100 ; i++ )

to

for ( unsigned int i = 100 -1 ; i >= 0 ; --i )

you get an infinite loop

And who ever did the refactoring and checked that code into the repository
should be reprimanded/re-educated.

[Julie]

Song Yun Zhao wrote:

Hi,

Just wondering what are the dis/advantages of using uint vs int. When
would be the best time to use it?

Use the type that is most suitable for your domain.

If the domain is non-negative integers less than UINT_MAX, use unsigned int.

If the doamin is integers in the range of INT_MIN and INT_MAX, use (signed) int.

etc.

[red floyd]

Song Yun Zhao wrote:

Jonathan Turkanis wrote:

I meant to say mountain_range. Now is everything clear?

not really, r u trying to say that uint is not a standard type?

Song

Yes, that's exactly what he's trying to say. Since uint is not a
standard type, the usage depends on the application's definition of uint.

[rajkumar]

unless you want to redesign / refactor libraries you have to live with
it.

And who ever did the refactoring and checked that code into the repositoryshould be reprimanded/re-educated.

The idea here was that its more error prone... unless everybody else
(fellow developers) feels the same about int / unsigned int
it would be a bad idea

raj

[Thomas Matthews]

Song Yun Zhao wrote:

Hi,

Just wondering what are the dis/advantages of using uint vs int. When
would be the best time to use it? Generally, uint is often followed by the number of bits. This is
often found in embedded systems, where the bit-width of a variable
is important. For example:
#define UINT8 unsigned char
#define UINT16 unsigned short
#define UINT32 unsigned int
This is primarily used to make porting to other platforms easier,
but that is a whole separate and lengthy topic.
Anyway all comments are appricated. TIA. You should search the newsgroup. There have been many heated
discussions about signed versus unsigned integers and when
to use them. One person suggested that the unsigned integer
type be removed from the language.

My own personal belief is that unsigned should be used for
ordinal types, where the value is never negative, such as
counting fruit. Unsigned is also used when all the bits
of an integer are used. Signed integers are used when
the value can go negative, such as temperatures in Fahrenheit.

For small quantities or values, your best bet is to spend
time doing something else than worrying about this issue.
For example, on most platforms, the number 4
can be easily handled in the native integral datatype; so
the point of using signed versus unsigned is moot.

Song

--
Thomas Matthews.

[Owen Jacobson]

On Tue, 08 Mar 2005 15:55:17 +1100, Song Yun Zhao wrote:

Jonathan Turkanis wrote:

I meant to say mountain_range. Now is everything clear?

not really, r u trying to say that uint is not a standard type?

Exactly.

Many platforms provide a 'uint' type that is either an alias or a typedef
from 'unsigned int', but this is in no way guaranteed by the C++ standard.
I don't think anyone here honestly didn't understand you, but in the
future you should use the standard type.

[Song Yun Zhao]

Howard wrote:

"unsigned int", just like I see you writing "u r" instead of "you are", then
please refrain from doing that. We really need to stay technically accurate
here (as much as possible, anyway). Thanks.

no worries, I'll stick to the standard next time. thanks.

make it as effective as possible. So I feel that using an int where only
an uint is needed is a waste.

What is "wasted"?

an unsigned int could be better used to represent a bigger range of
positive integers (obviously 0-2^32, assuming a 32 bit platform),
whereas an int can only represent up to 2^31 positive integers. So if I
know that a number is always going to be a positive integer, I feel like
I'm wasting some "range". The same reason you would use a char instead
of a short int etc.

Calling foobar(-1) will change the -1 to an unsigned int (assuming that uint
is the same as unsigned int), and will result in a very large positive
integer, which is obviously greater than 0. Also, the code above will issue
a warning no matter what you pass as the parameter, since an unsigned int is
agreed, therefore my compiler (GNU g++) gives me *two* warnings, which
serves as an indication that I'm doing something not right.
I use unsigned int (or char, or short, or long) where I think it's
appropriate. They pay me to think here, so I do. :-)

I probably speak less than 10 words (hi, morning, g'day, well you get
the idea) to ppl at work each day, guess what I do the rest of the time?
;) Probably doesn't do much good to my communication/social skills, but
hey I'm a programmer. :(

cheers

[Ioannis Vranos]

Howard wrote:

Using unsigned
int just takes a little longer to write than int. It is not likely to
effect your performance at all.

He can just type "unsigned" instead of "unsigned int". :-)

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Stefan Strasser]

Ioannis Vranos schrieb:

Howard wrote:

Using unsigned int just takes a little longer to write than int. It
is not likely to effect your performance at all.

although I don't agree that's a reason to use signed in interfaces:
http://www.aristeia.com/Papers/C++Re...umns/sep95.pdf

[msalters]

ee****@psu.edu wrote:

I don't know of any reason why it would make a speed difference, but it is not there just for backwards compatibility by any stretch of
imagination.

Remember that the types are different sizes. Have data that can range
up to, say, 4 billion but you can gurantee will be positive? You gotta use an unsigned int.

No, use unsigned long.

unsigned int is guaranteed to be non-negative, but it may be as small
as 16 bits. long has to be 32 bits.

Regards,
Michiel Salters

[Michael Etscheid]

msalters schrieb:

No, use unsigned long.

unsigned int is guaranteed to be non-negative, but it may be as small
as 16 bits. long has to be 32 bits.

No. §3.9.1 says:

3. For each of the signed integer types, there exists a corresponding
(but different) unsigned integer rype: "unsigned char", "unsigned short
int", "unsigned int", and "unsigned long int," each of which occupies
the same amount of storage and has the same alignment requirements (3.9)
as the corresponding signed integer type; [...]

And now let's see to the signed integer types:

2. There are four signed integer types: "signed char", "short int",
"int", and "long int". In this list, each type provides at least as much
storage as those preceding it in the list. Plain ints have the natural
size suggested by the architecture of the execurtion environment (that
is, large enough to contain any value in the range of INT_MIN and
INT_MAX, as defined in the header <climits>); the other signed integer
types are provided to meet special needs.
You see that the amount of storage of long is just as inexact as that of
int.

[Ioannis Vranos]

Michael Etscheid wrote:

No. §3.9.1 says:

3. For each of the signed integer types, there exists a corresponding
(but different) unsigned integer rype: "unsigned char", "unsigned short
int", "unsigned int", and "unsigned long int," each of which occupies
the same amount of storage and has the same alignment requirements (3.9)
as the corresponding signed integer type; [...]

And now let's see to the signed integer types:

2. There are four signed integer types: "signed char", "short int",
"int", and "long int". In this list, each type provides at least as much
storage as those preceding it in the list. Plain ints have the natural
size suggested by the architecture of the execurtion environment (that
is, large enough to contain any value in the range of INT_MIN and
INT_MAX, as defined in the header <climits>); the other signed integer
types are provided to meet special needs.
You see that the amount of storage of long is just as inexact as that of
int.

There is the guarantee that signed and unsigned:

short and int can hold at least 16 bit integer values, long at least
32-bit values and char at least 8-bit values.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Clark S. Cox III]

On 2005-03-11 09:18:15 -0500, Michael Etscheid <th***********@gmail.com> said:

msalters schrieb:

No, use unsigned long.

unsigned int is guaranteed to be non-negative, but it may be as small
as 16 bits. long has to be 32 bits.
No. §3.9.1 says:

[snip]
Plain ints have the natural size suggested by the architecture of the
execurtion environment (that is, large enough to contain any value in
the range of INT_MIN and INT_MAX, as defined in the header <climits>);
the other signed integer types are provided to meet special needs.
But INT_MIN must be less than or equal to -32767, and INT_MAX must be
greater than or equal to 32767. This makes it impossible for an
implementation to give an int less than 16 value bits.

By the same token, the smallest acceptable values for LONG_MIN and
LONG_MAX force long to have at least 32 value bits.
You see that the amount of storage of long is just as inexact as that of
int.

But there are minimums specified. If the following program prints
anything, then your compiler is broken:

#include <iostream>
#include <climits>

int main()
{
if(sizeof(char) != 1 || CHAR_BIT < 8 ||
sizeof(short) < sizeof(char) || CHAR_BIT * sizeof(short) < 16 ||
sizeof(int) < sizeof(short) || CHAR_BIT * sizeof(int) < 16 ||
sizeof(long) < sizeof(int) || CHAR_BIT * sizeof(long) < 32)
{
std::cout << "Your compiler is broken\n";
}
return 0;
}
--
Clark S. Cox, III
cl*******@gmail.com

[Julie]

Richard Herring wrote:

In message <4NkXd.49419$xt.15977@fed1read07>, Julie <ju***@nospam.com>
writes

ra******@hotmail.com wrote:

Hey
Lots of functions return 0 - N for okay and -1 for error conditions.

Indication of poor design: using a value to indicate both a value and
an error condition, should be separate variables or an exception.

You won't be in favour of using the STL, then.
std::find returns the "end" iterator if it can't find a match.
string functions return npos. And so on.

I don't see how cluttering the interface with an extra returned value
would help matters, and failure to find a match isn't usually the kind
of unexpected event that exceptions were intended to handle.

I'm talking about /error/ conditions.

'Not found' and similar are not errors, but indicators.

[Michael Etscheid]

Ioannis Vranos wrote:

There is the guarantee that signed and unsigned:

short and int can hold at least 16 bit integer values, long at least
32-bit values and char at least 8-bit values.

Where can I read that?

[Ioannis Vranos]

Michael Etscheid wrote:

short and int can hold at least 16 bit integer values, long at least
32-bit values and char at least 8-bit values.

Where can I read that?

It was inherited from C90.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Richard Herring]

In message <YLjYd.52672$xt.51867@fed1read07>, Julie <ju***@nospam.com>
writes

Richard Herring wrote:

In message <4NkXd.49419$xt.15977@fed1read07>, Julie
<ju***@nospam.com> writes

ra******@hotmail.com wrote:

Hey
Lots of functions return 0 - N for okay and -1 for error conditions.
Indication of poor design: using a value to indicate both a value
and an error condition, should be separate variables or an exception. You won't be in favour of using the STL, then.
std::find returns the "end" iterator if it can't find a match.
string functions return npos. And so on.
I don't see how cluttering the interface with an extra returned
value would help matters, and failure to find a match isn't usually
the kind of unexpected event that exceptions were intended to handle.

I'm talking about /error/ conditions.

So, I suspect, was the OP, despite his use of the word "error".
'Not found' and similar are not errors, but indicators.

Indeed, but they still use a special "value" to indicate something that
isn't a value at all. Is that an indication of poor design?

--
Richard Herring

[Rolf Magnus]

Song Yun Zhao wrote:

make it as effective as possible. So I feel that using an int where only
an uint is needed is a waste.

What is "wasted"?

an unsigned int could be better used to represent a bigger range of
positive integers (obviously 0-2^32, assuming a 32 bit platform),
whereas an int can only represent up to 2^31 positive integers. So if I
know that a number is always going to be a positive integer, I feel like
I'm wasting some "range".

What if you need to have differences, offsets - or whatever you want to call
it - between two of those values? Such an offset might be negative, and
then you get into trouble.
The same reason you would use a char instead of a short int etc.

I would use char or short instead of int only if I have to store lots of
those values, i.e. I can significantly reduce memory utilization.
Typically, it's best to use int, since that type is supposed to have the
native size of the machine, making it potentially faster than the other
types.

[Julie]

Richard Herring wrote:

You won't be in favour of using the STL, then.
std::find returns the "end" iterator if it can't find a match.
string functions return npos. And so on.
I don't see how cluttering the interface with an extra returned
value would help matters, and failure to find a match isn't usually
the kind of unexpected event that exceptions were intended to handle.

I'm talking about /error/ conditions.

So, I suspect, was the OP, despite his use of the word "error".

'Not found' and similar are not errors, but indicators.

Indeed, but they still use a special "value" to indicate something that
isn't a value at all. Is that an indication of poor design?

In terms of C/C++, I'd say that return values that indicate a legitimate value
or an error is a flag for potential poor design. True errors should be handled
by exceptions. Return values that also double as indicators (e.g. not found) I
think are worth a second look and may be questionable design.

On the whole, and off-topic here, I think that the /language/ is severely
deficient in its parameter input and return value handling.
Single-return-value functions are far too limiting, and [out] parameters just
lead to clutter, language hacks (pointers/references), etc. Again, not topical
here.

[Ioannis Vranos]

Julie wrote:

On the whole, and off-topic here, I think that the /language/ is
severely deficient in its parameter input and return value handling.
Single-return-value functions are far too limiting, and [out] parameters
just lead to clutter, language hacks (pointers/references), etc. Again,
not topical here.

I think you should check the std::pair as a return value.

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Julie]

Ioannis Vranos wrote:

Julie wrote:

On the whole, and off-topic here, I think that the /language/ is
severely deficient in its parameter input and return value handling.
Single-return-value functions are far too limiting, and [out]
parameters just lead to clutter, language hacks (pointers/references),
etc. Again, not topical here.

I think you should check the std::pair as a return value.

Any structure can be returned from a function, but then you must cache that
value (i.e. new variable) or just use a single field.

Again, my ideas aren't topical here, but I think that C/C++ parameter handling
is so 1960's.

[Ioannis Vranos]

Julie wrote:

I think you should check the std::pair as a return value.

Any structure can be returned from a function, but then you must cache
that value (i.e. new variable) or just use a single field.

Again, my ideas aren't topical here, but I think that C/C++ parameter
handling is so 1960's.

What about returning pointers for run-time/space expensive values?

--
Ioannis Vranos

http://www23.brinkster.com/noicys

[Richard Herring]

In message <1110937742.797469@athnrd02>, Ioannis Vranos
<iv*@remove.this.grad.com> writes

Julie wrote:

I think you should check the std::pair as a return value.

Any structure can be returned from a function, but then you must
cache that value (i.e. new variable) or just use a single field.
Again, my ideas aren't topical here, but I think that C/C++
parameter handling is so 1960's.

What about returning pointers for run-time/space expensive values?

What about being really revolutionary and returning a special sentinel
value to indicate special cases like "not found"? ;-) It's a good
solution for half-open sequences, where there's a natural choice ('end')
for the flag value, and this is reflected in the simplicity of many of
the algorithms.

--
Richard Herring

[Julie]

Ioannis Vranos wrote:

Julie wrote:

I think you should check the std::pair as a return value.

Any structure can be returned from a function, but then you must cache
that value (i.e. new variable) or just use a single field.

Again, my ideas aren't topical here, but I think that C/C++ parameter
handling is so 1960's.

What about returning pointers for run-time/space expensive values?

Again, a hack for a language deficiency.

Maybe it is time that I design my own language.

[Ioannis Vranos]

Julie wrote:

Again, a hack for a language deficiency.

Maybe it is time that I design my own language.

Perhaps it is. Wait a minute, I thought Java was the cure for all
problems! :-)

--
Ioannis Vranos

http://www23.brinkster.com/noicys