const_cast question

[Gajanan Bhat]

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

 

[Sharad Kala]

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

 

[Rolf Magnus]

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.

 

[Bill Seurer]

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

 

[Siemel Naran]

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

 

[George Privalov]

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.

 

[Jeff Schwab]

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.

 

[Siemel Naran]

George Privalov wrote:

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?

 

[Jeff Schwab]

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

Never. Sorry, I misread your post.

 

[Bill Seurer]

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.