when to use uint? dis/advantages?

[Stefan Strasser]

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

 

[msalters]

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

 

[Richard Herring]

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.[/QUOTE]

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.

 

[Michael Etscheid]

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]

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.

 

[Clark S. Cox III]

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;
}

 

[Michael Etscheid]

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?

 

[Julie]

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.

 

[Ioannis Vranos]

Where can I read that?

It was inherited from C90.

 

[Richard Herring]

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.[/QUOTE]

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?

 

[Rolf Magnus]

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]

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



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]

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:air as a return value.

 

[Julie]

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

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?

 

[Richard Herring]

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.

 

[Julie]

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]

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!