Thread: Tricky const ;)

Please take a look at this:

//--------------------
const int x = 5; // 1
int u, v;

*(int*)&x = 9; // 2

u = x; // 3
v = *(int*)&x;
//--------------------
Watch x values while debugging, say at lines 1, 2 and 3.

Question: what's the final value for u and v after executing these lines of code?

WHY?? ;°))

Huh????

WTF....that's wierd.......


Going to think on that.....

Depends on compiler and OS. *nix systems actually put your constants into read-only memory locations, which throw access violations if you try to write to them through some trick at runtime. Lets assume this is running on 9x, which probably lets you write any memory location.

As your compiler knows x is a constant 5, it may optimize u = x;
to u = 5; which would probably safe him one or two instructions depending on cache.


const int x = 5; // 1
// x is 5... I would hope so for your compiler

int u, v;

*(int*)&x = 9; // 2
// if there is a mem-location associated with x, it's value is now changed to 9. It might as well crash because it's read only memory ( OS-specific )

u = x; // 3
// depending on optimization, this might be a lookup on x, so u is 9, or if optimized, it would result in u = 5;

v = *(int*)&x;
// looking into memory should give the value we wrote ( if it did not crash ), so v should be 9

This is theory, I did not run it through a debugger...
If any other result shows up, enlight me

Ok, but what does ANSI C++ say? Is it allowed to do such trickery? If yes, then it should work with every compiler...

If you write *&x = 9 you get a compiler error, as the *& points to the value found on x's address, INCLUDING it's attributes (const).
BUT, doing the *(int*)&x conversion, the address of x is first casted to an int type pointer, and the const attribute is lost!

Why that?

P.s.
Please notify me if you get *any* compiler warning, and tell me, which compiler are you using.

Thanks!

>>Please notify me if you get *any* compiler warning, and tell me, which compiler are you using.

Compiled AOK with DevC++4......no objection.............no runtime errors either.......

....Compiled and run on Win98 though

Hmm, interesting.

Indeed, the u = x instruction is optimized to x = 5.
That's what I've got in my disassembly window:

>> 13: u = x;
>> 0040D686 mov dword ptr [ebp-8],5

No warnings in VC6 SP5 Win2K.



*&x = 9; ( ERROR: lvalue is a constant )


With the ERROR:

x is a const int
&x is a const int* const
*&x is a const int&
*&x = 9 is an error


Without ERROR:

x is a const int
&x is a const int* const
(int*)&x is an int* ( you could have casted it into an CElephant*, the compiler would have taken it as CElephant* from there on )
*(int*)&x is an int&
*(int*)&x = 9 is correct.

btw. the writer of our coding standards ( me ) will have you for lunch if you ever cast a const to non-const.

Syntactically, it's correct, from the philosophy side, it's a hack.

nvoigt >>

btw. the writer of our coding standards ( me ) will have you for lunch if you ever cast a const to non-const.

I take it as a way of direct-accessing a memory region.
Call it hacking, it's ok for me ;°).

P.s.
Does it work with C#?