Yannick Moy wrote:
> The standard says in 12.1.15 that:
>
> "During the construction of a const object, if the value of the
object
> or any of its subobjects is accessed though an lvalue that is not
> obtained, directly or indirectly, from the constructor's this
pointer,
> the value of the object or subobject thus obtained is unspecified."
>
> An example follows:
>
> struct C;
> void no_opt(C*);
>
> struct C {
>   int c;
>   C() : c(0) { no_opt(this); }
> };
>
> const C cobj;
>
> void no_opt(C* cptr) {
>   int i = cobj.c * 100;    // value of cobj.c is unspecified
>   cptr->c = 1;
>   cout << cobj.c * 100     // value of cobj.c is unspecified
>        << '\n';
> }
>
> I guess it has to do with putting the const object in read-only
> memory, but what is the exact rationale behind this point ?
> How is it implemented in compilers ?

I think it's not only read-only memory. This allows compilers to
optimize more. In particular, a compiler can determine the possible
values of a const object if it can see all assignments in ctors.

E.g. in
void no_change( );

struct C {
  int c;
  C() : c(0) { no_change( ); }
};

the compiler can know that any const C object has c==0. There is
no legal way in which no_change can change c. It's similar to the
restrictions for const_cast. Also, the compiler might reorder the
assignment to members (possibly even in parallel with other code),
but not in this case. (because of non-const C objects).

Regards,
Michiel Salters

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Yannick Moy wrote:
>
> const C cobj;
>
> void no_opt(C* cptr) {
>   int i = cobj.c * 100;    // value of cobj.c is unspecified
>   cptr->c = 1;
>   cout << cobj.c * 100     // value of cobj.c is unspecified
>        << '\n';
> }
>
> I guess it has to do with putting the const object in read-only
> memory, but what is the exact rationale behind this point ?

I think this has little to do with read-only memory. Put yourself in the
compiler's shoes: it cannot nearly imagine that the line "cptr->c = 1;"
has a side-effect that modifies cobj, which has been declared const.
Therefore the compiler may decide to optimize the second "cobj.c"
sub-expression by reusing whatever cached value it may have from
evaluating the first one. In other words the code above may be
interpreted as

void no_opt(C* cptr) {
   int i = cobj.c * 100;
   cptr->c = 1;
   cout << i << '\n';
}

and such an optimization would be perfecly legal. The fact that the
value of  "i" is also unspecified is a different issue, but I think you
got the point.

Alberto

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

The standard says in 12.1.15 that:

"During the construction of a const object, if the value of the object
or any of its subobjects is accessed though an lvalue that is not
obtained, directly or indirectly, from the constructor's this pointer,
the value of the object or subobject thus obtained is unspecified."

An example follows:

struct C;
void no_opt(C*);

struct C {
  int c;
  C() : c(0) { no_opt(this); }
};

const C cobj;

void no_opt(C* cptr) {
  int i = cobj.c * 100;    // value of cobj.c is unspecified
  cptr->c = 1;
  cout << cobj.c * 100     // value of cobj.c is unspecified
       << '\n';
}

I guess it has to do with putting the const object in read-only
memory, but what is the exact rationale behind this point ?
How is it implemented in compilers ?
Are there examples of people who suffered from not knowing this point
?

There is a discussion back on december 2003 (started the 17th) that
alludes to this point, but it does not answer my questions.

Thanks.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]