Re: new concept checks and the 3.0 ABI

[Benjamin Kosnik <bkoz at redhat dot com>]

> Now, I do see your point -- it can be argued that we just aren't ready.
> libstdc++-v3 still isn't stable enough to have its ABI frozen; we haven't
> really taken advantage of factoring to reduce bloat from the STL (e.g.
> using the same code for vector<T> for T's that are POD's, and having that
> code in the library), and we don't really know if we're doing everything
> the best way.

Right. There's a bunch of things: the allocator API, what we eventually 
do with a thread library, and finishing off named locales strike me 
immediately.

> Maybe we'll have to aim for compiler ABI freeze in 3.0, library in 3.1
> (in the sense of glibc: changes are backward compatible).  But we do need
> to think about how to achieve a library ABI freeze.

Thanks for taking the time to explain yourself...I now understand the issue.

There's no way I can assert that libstdc++.3.1 will be link-compatible 
with the libstdc+++.3 that is shipped with gcc-3. We can, however, try to 
back port patches to the API so that libstdc++.3.0.1 is link compatible 
with gcc-3. Sound ok? We can fix the non-breaking bugs on the 
gcc-3_0-branch.

For gcc-3.1 I think we should use whatever the latest stable release of 
libstdc++ is. 

-benjamin