Surprising Problem

Hello Friends
Can anyone help me where exactly at what address the *p is storing the
updated value ( which is 99).

const int k=9;

int *p=(int *)&k;

cout<<"Addr of k : "<<&k<<" "<<p;

*p=99; //here *p has updated the value of k

cout<<"Addreses\n"<<&(*p)<<&k; //BOTH the addresses are same.

cout<<"values \n"<<*p<<k; //But still the values are differentl.

what exaclty is happening here...??
Thanks

re: Surprising Problem

codergem@gmail.com wrote:
You can't change the value of constants, though you can take it's
address... and attempt to modify it via the pointer. The compiler does
const folding to reduce the value of expressions involving constants at
compile time, that's why you are seeing this behavior.

-
SJ

re: Surprising Problem

* codergem@gmail.com:Undefined Behavior (UB), because: modifying an originally const variable.

Or, practically speaking, that you have told the compiler that it can
rely on k being constant, so that it can use the original value directly
wherever it's needed. When you request the address of k you get the
address of a location containing that value. But that doesn't mean the
compiler needs to (generate code to) retrive the value from that
location where the value is used; you've explicitly told the compiler
that it doesn't need to, that the value is constant, unchanging.

However, formally none of that reasoning holds, because you have UB.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

re: Surprising Problem

codergem@gmail.com wrote:^^^^^
no, it has not. You previously declared that k won't change, marking it
const. What you actually do in above line is invoking undefined
behaviour - you misled the compiler, thus compiler is free to do
anything.


B.

re: Surprising Problem

codergem@gmail.com wrote:like above, you want to change the constant via a pointer which pointe
to it,I think it will work .
the k 's address are the same as p while the values are not, I think
the compiler maybe optimize the constants, like puting them in the
register. so try to add a votatile keywords in front of the definition
of k:
volatile const int k = 9; ///looks very funny
the result may be what you want ( I only test it in VC8.0 ) :-)

re: Surprising Problem

codergem@gmail.com wrote:
'k' is a constant object. Its value cannot be changed. An attempt to cast away
constness of 'k' and "change" its value (which is what you do above) will only
lead to undefined behavior. That's what happens in your case.

--
Best regards,
Andrey Tarasevich

re: Surprising Problem

codergem@gmail.com posted:

Equivalent to:

int *p = const_cast<int*>(&k);


7.1.5.1/4:

Any attempt to modify a const object during its lifetime results in
undefined behavior.


The beauty of undefined behaviour.

--

Frederick Gotham

re: Surprising Problem

codergem@gmail.com wrote:Why do you call this "surprising problem"? You have broken the
restrictions on well-defined programs by telling the compiler a variable
is const and then changing it. Now it doesn't do what you expect it to.
Why do you expect any particular answer? The program has undefined
behaviour. That's that. Write programs that obey the standard and _then_
you have cause to query happenings outside what the standard predicts.
But here, even if anyone explains some mechanism that cause this result,
and even if you find some other kludge that makes it give the output you
want, what on earth makes you think that it will still give the output
you want if compiled by another compiler, or even by the same compiler
after a version upgrade? I mean, it's not rocket physics; you can guess
that this is undefined even without looking at the standard: you are
telling porkies to the compiler.

--
Ron House house@usq.edu.au
http://www.sci.usq.edu.au/staff/house