const_cast question

Discussion in 'C++' started by Gajanan Bhat, May 4, 2004.

  1. Gajanan Bhat

    Gajanan Bhat Guest

    Hi,

    When i run this piece of code.....i get the following result...

    const int w = 10;
    int * wp = const_cast<int *> (&w);

    *wp = 20;

    cout << w << endl << &w << endl << wp << endl << *wp << endl;

    Output :

    10
    0012F58C
    0012F58C
    20

    can any1 explain y this happens even though &w and wp
    are the same?

    Gajanan
    Gajanan Bhat, May 4, 2004
    #1
    1. Advertising

  2. Gajanan Bhat

    Sharad Kala Guest

    "Gajanan Bhat" <> wrote in message
    news:xUHlc.5152$...
    > Hi,
    >
    > When i run this piece of code.....i get the following result...
    >
    > const int w = 10;
    > int * wp = const_cast<int *> (&w);
    >
    > *wp = 20;
    >
    > cout << w << endl << &w << endl << wp << endl << *wp << endl;
    >
    > Output :
    >
    > 10
    > 0012F58C
    > 0012F58C
    > 20
    >
    > can any1 explain y this happens even though &w and wp
    > are the same?


    Because this is undefined behavior.
    You first promise the compiler that w is const and then cast away it's
    const-ness. Compiler then gets the freedom to do whatsoever it wants!

    -Sharad
    Sharad Kala, May 4, 2004
    #2
    1. Advertising

  3. Gajanan Bhat

    Rolf Magnus Guest

    Gajanan Bhat wrote:

    > Hi,
    >
    > When i run this piece of code.....i get the following result...
    >
    > const int w = 10;
    > int * wp = const_cast<int *> (&w);
    >
    > *wp = 20;
    >
    > cout << w << endl << &w << endl << wp << endl << *wp << endl;
    >
    > Output :
    >
    > 10
    > 0012F58C
    > 0012F58C
    > 20
    >
    > can any1 explain y this happens even though &w and wp
    > are the same?


    Yes, you invoked undefined behaviour by creating an object as const and
    then casting the constness away. If you define the object as const, the
    compiler is allowed to assume that its value will never change.
    Questions like yours can be seen very often, and I wonder why so many
    people want to define objects as const just to cast the constness away,
    and what they think why const is there in the first place.
    Rolf Magnus, May 4, 2004
    #3
  4. Gajanan Bhat

    Bill Seurer Guest

    Rolf Magnus wrote:
    > ...I wonder why so many
    > people want to define objects as const just to cast the constness away,
    > and what they think why const is there in the first place.


    People want their code to be as fast as possible so they throw in all
    the "tricks" they have learned (or just heard of) to make it faster even
    if their code breaks the "contract" that those tricks require. It's
    fairly obviously for something like this but a lot trickier other times.
    I see this quite frequently with the aliasing rules and optimization
    in my compiler work.
    Bill Seurer, May 4, 2004
    #4
  5. Gajanan Bhat

    Siemel Naran Guest

    "Gajanan Bhat" <> wrote in message news:xUHlc.5152

    > When i run this piece of code.....i get the following result...
    >
    > const int w = 10;
    > int * wp = const_cast<int *> (&w);
    >
    > *wp = 20;
    >
    > cout << w << endl << &w << endl << wp << endl << *wp << endl;
    >
    > Output :
    >
    > 10
    > 0012F58C
    > 0012F58C
    > 20
    >
    > can any1 explain y this happens even though &w and wp
    > are the same?


    Because wp is the address of w, regardless of const modifiers.

    BTW, a highly optimizing compiler would probably generate code that would
    crash the machine. As w is a const object, it will be placed in read-only
    memory as part of the compiled program, and any attempt to modify it will be
    a memory access violation.

    The compiler may also note that *wp is the same as w and therefore output
    the following (note the last line is different):

    10
    0012F58C
    0012F58C
    10
    Siemel Naran, May 4, 2004
    #5
  6. Bill Seurer <> wrote in message news:<c7801c$1e8q$>...
    > People want their code to be as fast as possible so they throw in all
    > the "tricks" they have learned (or just heard of) to make it faster even
    > if their code breaks the "contract" that those tricks require. It's
    > fairly obviously for something like this but a lot trickier other times.
    > I see this quite frequently with the aliasing rules and optimization
    > in my compiler work.


    I can not come up with one example when casting away constness should
    improve the code's performance. Would't it be easier for compiler to
    deal with simple and clear intent code rather than think what the
    particular writer was assuming about performance of this or that
    architecture?

    G.
    George Privalov, May 4, 2004
    #6
  7. Gajanan Bhat

    Jeff Schwab Guest

    George Privalov wrote:
    > Bill Seurer <> wrote in message news:<c7801c$1e8q$>...
    >
    >>People want their code to be as fast as possible so they throw in all
    >>the "tricks" they have learned (or just heard of) to make it faster even
    >>if their code breaks the "contract" that those tricks require. It's
    >>fairly obviously for something like this but a lot trickier other times.
    >> I see this quite frequently with the aliasing rules and optimization
    >>in my compiler work.

    >
    >
    > I can not come up with one example when casting away constness should
    > improve the code's performance.


    The compiler can sometimes assume cached values have not been modified
    if the corresponding variables have been declared const. This may
    improve performance. Also, const function arg's passed semantically by
    reference actually can be copied, so that accessing the arg's value does
    not require dereferencing.

    > Would't it be easier for compiler to
    > deal with simple and clear intent code rather than think what the
    > particular writer was assuming about performance of this or that
    > architecture?


    Usually.
    Jeff Schwab, May 4, 2004
    #7
  8. Gajanan Bhat

    Siemel Naran Guest

    "Jeff Schwab" <> wrote in message
    > George Privalov wrote:


    > > I can not come up with one example when casting away constness should
    > > improve the code's performance.

    >
    > The compiler can sometimes assume cached values have not been modified
    > if the corresponding variables have been declared const. This may
    > improve performance. Also, const function arg's passed semantically by
    > reference actually can be copied, so that accessing the arg's value does
    > not require dereferencing.


    True for adding const, but casting away constness, how can that ever improve
    performance?
    Siemel Naran, May 5, 2004
    #8
  9. Gajanan Bhat

    Jeff Schwab Guest

    Siemel Naran wrote:
    > "Jeff Schwab" <> wrote in message
    >
    >>George Privalov wrote:

    >
    >
    >>>I can not come up with one example when casting away constness should
    >>>improve the code's performance.

    >>
    >>The compiler can sometimes assume cached values have not been modified
    >>if the corresponding variables have been declared const. This may
    >>improve performance. Also, const function arg's passed semantically by
    >>reference actually can be copied, so that accessing the arg's value does
    >>not require dereferencing.

    >
    >
    > True for adding const, but casting away constness, how can that ever improve
    > performance?


    Never. Sorry, I misread your post.
    Jeff Schwab, May 5, 2004
    #9
  10. Gajanan Bhat

    Bill Seurer Guest

    George Privalov wrote:

    > Bill Seurer <> wrote in message news:<c7801c$1e8q$>...
    >
    >>People want their code to be as fast as possible so they throw in all
    >>the "tricks" they have learned (or just heard of) to make it faster even
    >>if their code breaks the "contract" that those tricks require. It's
    >>fairly obviously for something like this but a lot trickier other times.
    >> I see this quite frequently with the aliasing rules and optimization
    >>in my compiler work.

    >
    >
    > I can not come up with one example when casting away constness should
    > improve the code's performance.


    No, no. The other way round. They stick in const thinking it makes the
    code faster and then break it by casting away const because the stuff
    really wasn't const to begin with.
    Bill Seurer, May 5, 2004
    #10
    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. Kaspar Minosiants

    [help] const_cast

    Kaspar Minosiants, Jul 21, 2003, in forum: C++
    Replies:
    2
    Views:
    412
    John Harrison
    Jul 21, 2003
  2. drowned

    const_cast question

    drowned, Aug 4, 2003, in forum: C++
    Replies:
    3
    Views:
    468
    Josephine Schafer
    Aug 4, 2003
  3. R. Anbeeswaran

    const_cast<>

    R. Anbeeswaran, Nov 13, 2003, in forum: C++
    Replies:
    7
    Views:
    585
    Ekkehard Morgenstern
    Nov 14, 2003
  4. , India
    Replies:
    4
    Views:
    512
    red floyd
    Nov 14, 2007
  5. Replies:
    4
    Views:
    423
    Alf P. Steinbach
    Feb 1, 2008
Loading...

Share This Page