About const_cast and volatileness

[Küržat]

Hi all,

I try to change value of a const int like this (This is only about
curiosity, not about any real problem solving) :

void chgval (int * p, int n)
{
if (p)
*p = n;
}

int main ()
{
const int cn = 21;

chgval (const_cast <int * > (&cn), 14);

cout << cn;
return 0;
}

The interesting point is that after chgval returns, watch window shows ch's
value as 14 but cout still prints 21. But if I make cn "volatile const" than
cout prints 14 which is consistent with the watch output. I think this is a
strange behavior for a single-threaded application. Could you please explain
internals of this behavior?

Thanks in advance.

[Ulrich Eckhardt]

Kürþat wrote:
> I try to change value of a const int

You can not legally change the values of constants.

> const int cn = 21;
>
> chgval (const_cast <int * > (&cn), 14);

This code is ill-formed. You may use const_cast<> to remove a
const-qualifier from a pointer or reference if the object it refers to
doesn't have that qualifier, but here it does.

Uli

--
C++ FAQ: http://parashift.com/c++-faq-lite

Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

[Manish Agarwal]

Here is assembly code for

cout << cn;
cout << xy; where xy is a non const int.

cout << cn;
00413618 mov esi,esp
0041361A push 15h
0041361C mov ecx,dword ptr [__imp_std::cout (418288h)]
00413622 call dword ptr
[__imp_std::basic_ostream<char,std::char_traits<char> >::operator<<
(41828Ch)]
00413628 cmp esi,esp
0041362A call @ILT+330(__RTC_CheckEsp) (41114Fh)

cout << xy;
0041362F mov esi,esp
00413631 mov eax,dword ptr [xy]
00413634 push eax
00413635 mov ecx,dword ptr [__imp_std::cout (418288h)]
0041363B call dword ptr
[__imp_std::basic_ostream<char,std::char_traits<char> >::operator<<
(41828Ch)]
00413641 cmp esi,esp
00413643 call @ILT+330(__RTC_CheckEsp) (41114Fh)

For const int compiler is directly refering its value i.e. const int is
replaced by its value at compile time only. Refer following asm statement-

0041361A push 15h

"Küržat" <kursat...@gmail.com> wrote in message
news:eooD5rWG...@TK2MSFTNGP05.phx.gbl...

[Küržat]

You mean this usage is legal :

void func (const int * p, int n)
{
int * ptr = const_cast <int * > (p);
*ptr = n;
}

int main ()
{
int n = 21;

func (&n, 14);

return 0;
}

Well, I know my original code is a crazy monster but what I wonder isn't
what is legal and what isn't. What I wonder is the reason of inconsistency
between cout and watch outputs and effect of the volatile.

"Ulrich Eckhardt" <eckh...@satorlaser.com> wrote in message
news:sqn9q5-...@satorlaser.homedns.org...

[Küržat]

It seems like the optimizer's joke!

"Manish Agarwal" <manish...@hotmail.com> wrote in message
news:Os8XJzXG...@TK2MSFTNGP04.phx.gbl...

[Ulrich Eckhardt]

Kürþat wrote:
> You mean this usage is legal :
>
> void func (const int * p, int n)
> {
> int * ptr = const_cast <int * > (p);
> *ptr = n;
> }
>
> int main ()
> {
> int n = 21;
>
> func (&n, 14);
>
> return 0;
> }

Yes, this code is well-formed.

> Well, I know my original code is a crazy monster but what I wonder isn't
> what is legal and what isn't. What I wonder is the reason of inconsistency
> between cout and watch outputs and effect of the volatile.

The optimiser makes the assumption that a constant doesn't change (because
it isn't allowed to). So, instead of reading the actual variable, it just
uses its (constant) value.

[Doug Harrison [MVP]]

On Thu, 18 Sep 2008 12:40:58 +0200, Ulrich Eckhardt
<eckh...@satorlaser.com> wrote:

>> const int cn = 21;
>>
>> chgval (const_cast <int * > (&cn), 14);
>
>This code is ill-formed. You may use const_cast<> to remove a
>const-qualifier from a pointer or reference if the object it refers to
>doesn't have that qualifier, but here it does.

That's undefined, not ill-formed. Actually, it only becomes undefined when
chgval tries to modify the aliased cn.

--
Doug Harrison
Visual C++ MVP

[Ben Voigt [C++ MVP]]

Küržat wrote:
> It seems like the optimizer's joke!

Joke? No. The optimizer is smart enough to know that the value of a const
variable never changes. Try following the same rule and everything will
work right.

[Küržat]

Let's say educational joke then :)

"Ben Voigt [C++ MVP]" <r...@nospam.nospam> wrote in message
news:%23eCBDWh...@TK2MSFTNGP04.phx.gbl...