Stroustrup's TC++PL(se) section 4.4

[Wayne Shu]

Now I'm reading Stroustrup's The C++ Programming Language(Special
Edition).

In section 4.4 Integer Types, he has wrote that "Using an unsigned
instead of an int to gain one more bit to represent positive integers
is almost never a good idea. Attempts to ensure that some values are
positive by declaring variables unsigned will typically be defeated by
the implicit conversion rules".

I can't understand the two sentences.

The first: "Using an unsigned instead of an int to gain one more bit
to represent positive integers is almost never a good idea."
Why? If int is represented as a two's complement method, it's true
that we can gain one more bit to represent positive integers using an
unsigned.

The second: "Attempts to ensure that some values are positive by
declaring variables unsigned will typically be defeated by the
implicit conversion rules".
In the implicit conversion rules, I think declaring variables signed
also has problems, why he explicit mentioned unsigned, but not signed?

Thanks for explaining it for me.


Regards.

 

[Emery]

Now I'm reading Stroustrup's The C++ Programming Language(Special
Edition).

In section 4.4 Integer Types, he has wrote that "Using an unsigned
instead of an int to gain one more bit to represent positive integers
is almost never a good idea. Attempts to ensure that some values are
positive by declaring variables unsigned will typically be defeated by
the implicit conversion rules".

I can't understand the two sentences.

The first: "Using an unsigned instead of an int to gain one more bit
to represent positive integers is almost never a good idea."
Why? If int is represented as a two's complement method, it's true
that we can gain one more bit to represent positive integers using an
unsigned.

The follow sentence explains why.

The second: "Attempts to ensure that some values are positive by
declaring variables unsigned will typically be defeated by the
implicit conversion rules".
In the implicit conversion rules, I think declaring variables signed
also has problems, why he explicit mentioned unsigned, but not signed?

Most APIs that operate on integers will apply to negatives as well so
signed ints are dominant.

 

[Bo Persson]

Wayne Shu wrote:
:: Now I'm reading Stroustrup's The C++ Programming Language(Special
:: Edition).
::
:: In section 4.4 Integer Types, he has wrote that "Using an unsigned
:: instead of an int to gain one more bit to represent positive
:: integers is almost never a good idea. Attempts to ensure that some
:: values are positive by declaring variables unsigned will typically
:: be defeated by the implicit conversion rules".
::
:: I can't understand the two sentences.
::
:: The first: "Using an unsigned instead of an int to gain one more
:: bit to represent positive integers is almost never a good idea."
:: Why? If int is represented as a two's complement method, it's true
:: that we can gain one more bit to represent positive integers using
:: an unsigned.

The real problem is that it genrally won't help. At least not for very
long.

Think about it, if your interface has parameters that don't fit in 31
bits, what are the odds that they will fit in 32 bits? How long will
it take before they sometimes need 33 bits?


:: The second: "Attempts to ensure that some values are positive by
:: declaring variables unsigned will typically be defeated by the
:: implicit conversion rules".
:: In the implicit conversion rules, I think declaring variables
:: signed also has problems, why he explicit mentioned unsigned, but
:: not signed?

You cannot assure that the parameter really is positive, because the
language allows you to assign negative values to an unsigned variable
or parameter.


The REAL problem occurs when you try to mix signed and unsigned types
in the same expression. That is really nasty! One way to avoid that is
to only use signed variables.


Bo Persson

 

[James Kanze]

Now I'm reading Stroustrup's The C++ Programming Language(Special
Edition).

In section 4.4 Integer Types, he has wrote that "Using an unsigned
instead of an int to gain one more bit to represent positive integers
is almost never a good idea. Attempts to ensure that some values are
positive by declaring variables unsigned will typically be defeated by
the implicit conversion rules".

I can't understand the two sentences.

The first: "Using an unsigned instead of an int to gain one more bit
to represent positive integers is almost never a good idea."
Why? If int is represented as a two's complement method, it's true
that we can gain one more bit to represent positive integers using an
unsigned.

Yes, but if you're that close to the limit, one more bit won't
really make a difference. All you're doing is setting a trap
for the future.

The second: "Attempts to ensure that some values are positive by
declaring variables unsigned will typically be defeated by the
implicit conversion rules".
In the implicit conversion rules, I think declaring variables signed
also has problems, why he explicit mentioned unsigned, but not signed?

The problem is simple: implicit conversion to an unsigned type
has defined semantics, and cannot be checked. So if you write
something like:

void f( unsigned v ) ; // v must be positive.
// ...
int i = -2 ;
f( i ) ; // error!

you won't get an error, either at runtime or compile time, but
rather an unexpected value as an argument. Whereas if you'd
declared "void f( int v )", it's trivial to write:

void
f( int v )
{
assert( v >= 0 ) ;
// ...
}

and get the checking you want.

 

[Wayne Shu]

Yes, but if you're that close to the limit, one more bit won't
really make a difference. All you're doing is setting a trap
for the future.


The problem is simple: implicit conversion to an unsigned type
has defined semantics, and cannot be checked. So if you write
something like:

void f( unsigned v ) ; // v must be positive.
// ...
int i = -2 ;
f( i ) ; // error!

you won't get an error, either at runtime or compile time, but
rather an unexpected value as an argument. Whereas if you'd
declared "void f( int v )", it's trivial to write:

void
f( int v )
{
assert( v >= 0 ) ;
// ...
}

and get the checking you want.

--
James Kanze (Gabi Software) email: (e-mail address removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Thank you and Bo Persson for explaining it for me.

 

[Paulo da Silva]

Wayne Shu escreveu:

If you still feel the need to use uints, you may look at your compiler
to see if it has some warning option to avoid you to make mistakes like
the one described. For gcc/g++ you may want to use -Wall -Wsign-compare
-Wconversion switches.