Re: new concept checks and the 3.0 ABI

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

> > (Would it be easier with the export stuff implemented, I'm not even
> > sure...).
> 
> Somewhat, as we wouldn't have to worry about the template code having been
> compiled into all of the users' .o's.  But it isn't implemented, so it's
> moot.

At least some of the template code compiled into the users' .o's may not
be a problem, as and the templates are self-contained.  This means that we
can do certain types of changes and still be safe, because the new
definitions would use different symbols, and the old definitions would
already exist in the executable.

Consider vector<T,Alloc>.  If the allocator is the default, or another
allocator that doesn't need instances, the data object is three pointers.
We are unlikely to change the meaning of those three pointers.  So if
we do some specialization so that all T's that are PODs have almost all
inline methods that call common code, and for the default allocator this
code would be in the library.  So if a program calls, say,
vector<T>::push_back(const T&) and has T=int, if it is old code it
will have the needed code in its .o, and if it's new it would call
some generic code in the library.

This kind of thing will work for some cases and fail in others, of course.
But changes that preserve the data representation in the STL classes
(while factoring out common code) can in many cases be made to work
in a backward-compatible way, and the fact that we don't do export
actually HELPS.