const usage in c++

I wrote such a piece of code:

const int i = 100;
int *p = (int *)&i;
*p = 200;

After the last line code was executed, variable i is still 100. Why?


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

chenwei225@gmail.com wrote:
> I wrote such a piece of code:
>
> const int i = 100;
> int *p = (int *)&i;
> *p = 200;
>
> After the last line code was executed, variable i is still 100. Why?
>

Short version: Because you are trying to fool your compiler and you
invoke undefined behaviour, so any output is valid.

Longer version: The optimiser knows that if you write "const int i =
100;", there is no way the value of i can ever change. Therefore
wherever you write i, the optimiser can replace it with 100 at compile time.

This is one of the problem with C-style casts, they are a blunt hammer,
and frequently it's easy to write things without realising that they are
invalid. If you'd used a static_cast (the general C++ replacement), the
code wouldn't compile. It would if you used a const_cast (which is
designed just to remove const), but before you used it, I would hope /
assume you'd read the documentation about it, which says you mustn't do
this kind of thing.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

chenwei225@gmail.com wrote:
> I wrote such a piece of code:
>
> const int i = 100;
> int *p = (int *)&i;
> *p = 200;
>
> After the last line code was executed, variable i is still 100. Why?

Modifying a true constant is undefined behavior. The compiler is free
to do anything in this case. It can substitute the value 100 for all
uses of i; it can actually modify the value of i; it can generate code
that will cause access violation (aka segmentation fault); it can even
change the value of 100 for the rest of the program.

Just don't do that.


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

chris jefferson wrote:

>>
>> This is one of the problem with C-style casts, they are a blunt
>> hammer, and frequently it's easy to write things without realising
>> that they are invalid. If you'd used a static_cast (the general C++
>> replacement), the code wouldn't compile. It would if you used a
>> const_cast (which is designed just to remove const), but before you
>> used it, I would hope / assume you'd read the documentation about it,
>> which says you mustn't do this kind of thing.
>>


Using const_case instead of a basic C-style cast doesn't actually
change anything in this case: the result is still undefined behaviour

While I agree that C-style casts are a blunt hammer, I wouldn't
characterise C++-style casts much differently. The only difference is
that C++ provides a set of blunt hammers, while C only provides one.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

> chris jefferson wrote:
> >> This is one of the problem with C-style casts, they are a blunt
> >> hammer, and frequently it's easy to write things without realising
> >> that they are invalid. If you'd used a static_cast (the general C++
> >> replacement), the code wouldn't compile. It would if you used a
> >> const_cast (which is designed just to remove const), but before you
> >> used it, I would hope / assume you'd read the documentation about it,
> >> which says you mustn't do this kind of thing.

Rob wrote:
> Using const_case instead of a basic C-style cast doesn't actually
> change anything in this case: the result is still undefined behaviour

Read chris jefferson's words again. They imply that const_cast wouldn't
get compile errors -- that doesn't mean that it isn't UB, and in fact
the phrase "the documentation...says you mustn't do this kind of thing"
kind of spells out the fact that it IS still a problem.


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

> const int i = 100;
> int *p = (int *)&i;
> *p = 200;

> Modifying a true constant is undefined behavior.

Hello, All.

Just one more question, what about volatile keyword?
Can I do something like:

volatile const int i = 100;
int * = (int*)&i;
*p = 200;
std::cout << i;

I try this example under VC7.0 and receive the same result.
Is this undefined behavior or compler bug?

With respect,
Alexander Kozlov


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

<syntetic@mail.ru> skrev i meddelandet
news:1130506861.099976.141820@g47g2000cwa.googlegr oups.com...
>> const int i = 100;
>> int *p = (int *)&i;
>> *p = 200;
>
>> Modifying a true constant is undefined behavior.
>
> Hello, All.
>
> Just one more question, what about volatile keyword?
> Can I do something like:
>
> volatile const int i = 100;
> int * = (int*)&i;
> *p = 200;
> std::cout << i;
>
> I try this example under VC7.0 and receive the same result.
> Is this undefined behavior or compler bug?

No, it's equally undefined.

Using volatile const means that the program cannot change the value,
but someone else might. That someone could be a hardware device, which
might be readable but not writeable.

Whenever you use a cast, you tell the compiler "Trust me, I know what
I am doing!". If you don't really know, it is almost always undefined
behaviour.

There is a contact between the programmer and the compiler, saying
that if you feed it valid program code, it has to compile it properly.
Whenever you invoke undefined behaviour, you have broken the contract,
and the compiler is free to do whatever it feels like. Anything can
happen.


Bo Persson



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]