Re: backwards compatibility/cross-compiler compatibility

[Nathan Myers <ncm@best.com>]

> How concerned are we about maintaining backwards compatibility (I don't mean
> for deprecated features in the standard, but stuff like "construct" and
> "destroy", which are left in for "backwards compatibility for HP STL").
> (Actually, that's a bad example because these "features" break our
> implementation namespace.)

We are concerned about standards compliance.  Code that depends on
features that are in violation of the standard is broken, and the 
sooner it begins to actually fail, the better.  (Stuff under ext/
is a separate matter.)
 
> Also, what is the classification of libstdc++? Are we a library only
> for egcs (in which case we can use compiler-specific optimization
> techniques), or are we a general-purpose library. If the latter, can
> we impose minimum requirements on the compilers that want to use the
> library (i.e., support member templates, etc.) so we can get rid of a
> lot of the #ifdef's, which (IMHO) clutter up the code? (They also make
> the code difficult to change, because a test compile with egcs only
> tests one element of all the possible permutations of these #define's;
> it would be easy to add a member function that works with egcs but
> breaks in a lesser compiler because all the testing is done with
> egcs.)

libstdc++ is a Standard C++ library.  It is for any compiler that 
implements the features it uses.  Over time its accommodations for 
compiler bugs must go down, not up, which means it shouldn't accept
#ifdefs to work around "new" bugs.

Support for unspecified aspects of the implementation will always
need adapation for specific compilers; those are not bugs.

Nathan Myers
ncm@cantrip.org