Re: more on the C++ abstraction penalty

[Joe Buck <jbuck at racerx dot synopsys dot com>]

>   It's good that you point out this optimization -- but I wish you
> wouldn't just now. :-)
> 
>   The reason is that we don't need this functionality for GCC 3.0; all
> we need is what we had in GCC 2.95.  I would prefer that we not
> encourage people to go trying to implement this now; I really want to
> batten down the hatches on new features.  It would be better to have
> people focused on getting out the bugs in GCC 3.0.

It depends on timing: is GCC 3.0 imminent, or is it still a long way off?
If the latter, I'd rather have a compiler that doesn't suck quite so
badly, and any extra pass over the tree can be structured as a completely
separate function that can be enabled or disabled at will (meaning its
risk is low).

Furthermore, you haven't announced any kind of schedules yet, eg when
is the feature freeze?  I'm still seeing much more ambitious changes
wrt the preprocessor being discussed without being similarly shot down.

In any case, ADDRESSOF should be fixed before any attempt is made to
add this optimization, as otherwise the failure is simply hidden, and
the C++ maintainers should focus on fixing release-critical bugs.