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

Discussion in 'C++' started by Wayne Shu, Jul 1, 2007.

  1. Wayne Shu

    Wayne Shu Guest

    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.
    Wayne Shu, Jul 1, 2007
    #1
    1. Advertising

  2. Wayne Shu

    Emery Guest

    On Jun 30, 8:20 pm, 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 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.
    Emery, Jul 1, 2007
    #2
    1. Advertising

  3. Wayne Shu

    Bo Persson Guest

    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
    Bo Persson, Jul 1, 2007
    #3
  4. Wayne Shu

    James Kanze Guest

    On Jul 1, 5:20 am, 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.


    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.

    --
    James Kanze (Gabi Software) email:
    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
    James Kanze, Jul 1, 2007
    #4
  5. Wayne Shu

    Wayne Shu Guest

    On Jul 1, 6:40 pm, James Kanze <> wrote:
    > On Jul 1, 5:20 am, 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.

    >
    > 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.
    >
    > --
    > James Kanze (Gabi Software) email:
    > 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.
    Wayne Shu, Jul 1, 2007
    #5
  6. Wayne Shu escreveu:
    > On Jul 1, 6:40 pm, James Kanze <> wrote:
    >> On Jul 1, 5:20 am, 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.

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



    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.
    Paulo da Silva, Jul 1, 2007
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. arnuld
    Replies:
    7
    Views:
    358
    Salt_Peter
    Oct 30, 2006
  2. arnuld

    Stroustrup section 2.5.1

    arnuld, Oct 31, 2006, in forum: C++
    Replies:
    3
    Views:
    296
    Default User
    Oct 31, 2006
  3. arnuld
    Replies:
    13
    Views:
    500
    Default User
    Nov 8, 2006
  4. arnuld
    Replies:
    2
    Views:
    286
    arnuld
    Nov 8, 2006
  5. arnuld
    Replies:
    6
    Views:
    376
    arnuld
    Nov 8, 2006
Loading...

Share This Page