Re: MSDN const_cast sample

From:

"Ben Voigt [C++ MVP]" <rbv@nospam.nospam>

Newsgroups:

microsoft.public.vc.language

Date:

Tue, 18 Dec 2007 09:08:53 -0600

Message-ID:

<#TfrxeYQIHA.4128@TK2MSFTNGP06.phx.gbl>

"George" <George@discussions.microsoft.com> wrote in message
news:DCC0E52E-4BBC-46F8-BEC0-6B552C760335@microsoft.com...

Hi Ben,

I have used Visual Studio 2008 tested your code works. The output is 425.

Under debug or release? Which optimizations enabled, if release?

I do not quite understand what do you mean,

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.

What do you mean *won't use the register* and *delay assigning*? Is it
some
special approaches to do optimization? Could you provide more descriptions
please?

regards,
George

"Ben Voigt [C++ MVP]" 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.