Re: libstdc++-v3 stability?

[Joe Buck <jbuck at synopsys dot COM>]

> > 1) The library ABI for gcc-3.1.x will remain fixed for the life of gcc-3.1.
> > This means no-ABI-breaking fixes in gcc-3.1.x's libstdc++. We tried to do 
> > this with gcc-3.0.x, but lack of symbol versioning got in the way.

Nathan writes:

> I think this is extreme.  It means, for example, that all substantial
> performance optimizations in iostream must be put off until the 3.2
> series.  Since iostream is currently about three orders of magnitude 
> -- that is *hundreds* of times -- slower than it should be, this is a
> serious matter.

This should not be news to you, it has been the rule for some time: we
always attempt to keep the C++ ABI (including libstdc++) stable across
changes to the third digit (though a couple of times we accidentally
violated this).  This has been the rule since the egcs days, and even
before, though it was deliberately violated in, I think, 2.7.2.

This is why some libstdc++ bug fixes that went into 3.0.3 had to be
changed, and in some cases made not as good.

So, at the risk of amusing Ben a bit more: if we put out a 3.1 that sucks
rocks, it is likely that 3.1.1 will also suck some of the same rocks.
One alternative is to think of things that can be done now that will
allow for more ABI-compatible performance improvements.

It is absolutely necessary that we follow this policy rigidly, so that
we can re-unify the GNU/Linux world, allowing for C++ binaries that
work on more than one distribution.

> I think we should, instead, identify a future release that we promise
> will be stable,

We would like to identify a future release where we promise that the
libstdc++ ABI will stay stable across even a change in the second digit,
but we aren't there yet, clearly.

The libstdc++ team can, of course, do what is already being done now,
in essence, putting out pre-releases that use experimental versions of
the next ABI (the one to be used with 3.2).