> Arch Robison <robison@kai.com> wrote:
> > (somebody) wrote
> > > This one has always bothered me - why isn't "const" enough to tell the
> > > compiler that x isn't being changed by the assignment.
> ...
> Const is almost useless for optimization. Consider a global declaration:
>
> const Foo x(2)
>
> Do I know that x never changes after initialization? I don't, because
> I could have:
>
> Foo * Munger;
>
> struct Foo {
> Foo( int j ) {...; Munger = this;}
> };
>
> That is, the constructor might "capture" the pointer to x for use later.
AFAIU, the above is not correct. Once the constructor for x has
returned (and until the destructor begins running), x is "really const",
and any modification via *Munger is undefined behavior. In other words,
the optimizer can assume it is really-const.
The difficulty for the compiler writer is determining, while compiling
other code, whether a reference to x happens while the constructor or
destructor is active. If so, then it's not "really const" yet (or,
any more). Practically, the effect is still that...
> As a writer of an optimizing compiler, I have to ignore "const",
> except for global variables declared as const that have static
> initializers. It's useless otherwise.
Nathan Myers
ncm@cantrip.org
--------------------- Object Oriented Numerics List --------------------------
* To subscribe/unsubscribe: use the handy web form at
http://oonumerics.org/oon/
* If this doesn't work, please send a note to owner-oon-list@oonumerics.org
This archive was generated by hypermail 2b29 : Wed Feb 20 2002 - 03:20:11 EST