Hi :

Let me first correct some semantic errors in the code.

> Try this sample C++ code on a solaris box.
>
>#include <stdio.h>
>int SetValue(const int &x)
>{
>    int &z = (int &)x ;
>    z = 10 ;
>    printf("address of x = %p - value of x = %d \n", &x, x) ;

    printf("address of z = %p - value of z = %d \n", &z, z) ;

>    return y ;
>}
>int main() {
>    const int y = 20 ;

    const int *ptr = &y ;

>
>    printf("address of y = %p - value of y = %d \n", &y, y) ;
>    SetValue(y) ;
>    printf("address of y = %p - value of y = %d \n", &y, y) ;

printf("value of y = %d", *ptr) ;

>return 0 ;
>}
>
>Can someone explain the result?
>
>Here is what I got -
>
>address of y = -268436400 - value of y = 10
>address of x = -268436400 - value of x = 20

address of z = -268436400 - value of z = 20

>address of y = -268436400 - value of y = 10
value of y = 20

I ran this code in VC++ and after looking at the assembly code found that
the compiler substitutes 14h at all places where the const y is being
called. so, at runtime even if the address space contents of y are changed
(as made sure by using ptr), y always remains 20 (like a macro
substitution).

cheers,
anand.

A NOTE : I am not sure if we can call the change of const value done above
(by explicit cast) as undefined. If it is undefined why doesn't the compiler
generate an error (it's pretty easy to detect this)?
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Anand J. Bhalerao wrote:

> I ran this code in VC++ and after looking at the assembly code found that
> the compiler substitutes 14h at all places where the const y is being
> called. so, at runtime even if the address space contents of y are changed
> (as made sure by using ptr), y always remains 20 (like a macro
> substitution).

That's a reasonable optimization in most cases. It's also the kind of
optimization that you may be able to disable with a command line switch.
I know you can with the Borland compiler.

--

Ciao,
Paul

(Please remove the extra "crud" from the return address,
which has been altered to foil junk mail senders.)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Anand J. Bhalerao <anand@abnar-telsoft.com> wrote in article
<5u4ss1$aqj$1@nntp1.ba.best.com>...
[Code cut.  A const int was passed by reference to a
 function accepting a const int reference, but which
 in fact attempted to change the referenced int. ]
> >Can someone explain the result?
[The result being that in the scope of the const int,
 the compiler used its known value instead of fetching
 the supposedly modified value.]
You claimed that int was const.  The compiler took
advantage of your claim to give you better code.  If
you want it treated as a variable (as in "can vary"),
just stop declaring it that way.

> I ran this code in VC++ and after looking at the assembly code found that
> the compiler substitutes 14h at all places where the const y is being
> called. so, at runtime even if the address space contents of y are changed
> (as made sure by using ptr), y always remains 20 (like a macro
> substitution).
Hooray for that compiler.

> A NOTE : I am not sure if we can call the change of const value done above
> (by explicit cast) as undefined. If it is undefined why doesn't the compiler
> generate an error (it's pretty easy to detect this)?

It may be easy to detect this particular lie, since the function
that effected the lie was in the same translation unit as the
call.  But such is not always the case and it would be a big
waste of compiler execution time and compiler development
time to try to catch that small fraction of lies which are
visible in a single compilation.  People who are intent on
creating such tangles can always find a way to outsmart an
attempt to untangle them.  What would be the point?  When
you used that cast, you were claiming to know what is going
on and what is supposed to happen.  Do you expect a compiler
to second guess what you're trying to do?

If I get to choose, I would have C++ compiler developers
concentrate on producing correct and efficient code for
sensible source and not worry about second guessing the
kind of shenanigans where a const is supposed to vary.

--
-- Larry Brasfield
The aforementioned views are mine alone.
(For e-mail reply, remove SpamGuard_.)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]