Re: MSDN const_cast sample
On Dec 18, 7:56 pm, "Ben Voigt [C++ MVP]" <r...@nospam.nospam> wrote:
"Abhishek Padmanabh" <abhishek.padman...@gmail.com> wrote in message
news:3daa8feb-f9ca-4572-8815-72933b7704bc@e6g2000prf.googlegroups.com...
On Dec 18, 12:16 am, "Ben Voigt [C++ MVP]" <r...@nospam.nospam> wrote:
Otherwise, a compiler is non-compliant if casting away const doesn't
work.
Assuming this code:
void mutate( int const& i) {
const_cast<int&>(i) = 42;
}
int i = 5;
mutate(i);
std::cout << i << std::endl;
I would assume the compiler to behave properly and output 42. Do you
know
of
any compilers that don't?
It should. It is only undefined behaviour if the variable/object being
modified was originally created as const. Here, i is not. And hence,
the modification should work. Don't know of a compiler that would go
against the above though.
I don't think "originally created as non-const" is sufficient.
For example:
void mutate( int const& i) {
const_cast<int&>(i) = 42;
}
void f(const int* const p)
{
int j = *p;
mutate(*p);
std::cout << *p << j << std::endl;
}
int i = 5;
f(&i);
I see no reason to believe that the compiler won't use the register used
to
hold j instead of reading memory again. For that matter, it is probably
allowable to delay assigning a value to j until after the call to mutate.
No reason until there is no const_cast applied. Herb Sutter's
I don't understand that statement.
All I know is that f isn't aware of the internal working of mutate, it just
knows the contract, which is that mutate receives a reference to const.
Therefore f can assume that *p cannot change and therefore can cache its
value throughout the function.
Yes, that is the contract and it is true that a function that takes a
reference to const and casts away const and modifies it is bad. But
the point I am making is that if the object when declared as non-
const, is passed to such a function, it is not undefined behavior. It
is only undefined behaviour if the object passed to this function was
a const object (const declaration for creating it). I am not saying
such functions are a good programming style, its bad bad bad since f()
can not really know if the constified object is actually a const or
not (may be with some effort but it won't make it a good function).
Here is a reference - http://groups.google.co.in/group/comp.lang.c++.moderated/msg/955f2471ef8d7801
- Note that the call f(poly) is fine. It does not result in undefined
behaviour because poly is not a const object. But cpoly is and hence
f(cpoly) is undefined behaviour.
I guess, when in f(), as soon as a const_cast is applied and the
object is non-const, the compiler has to make sure that it writes the
change at the memory where the object resides and not the cached value.