This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libstdc++-v3 stability?


On Thu, Feb 07, 2002 at 12:09:38PM -0800, Benjamin Kosnik wrote:
> 
> > My concern however is that while the C++ ABI may be stable, what
> > about the libstdc++ ABI?
> 
> Since it seems to be the issue of the day with OS vendors, I'll tell you 
> what I told them:
> 
> 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.

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.

Likewise, it doesn't allow for fixing thread-safety problems.

I think we should, instead, identify a future release that we promise
will be stable, and identify all the apparatus that must be added for
optimization (whether fully implemented or not) and put it in place
before that release.  After that release, we can fill in optimizations
(caching, etc) as we get contributions.
 
We should reserve extra space in base classes to add things like
locks and caches, using "long _M_dummy[N]" members.  We should 
reserve vtable cells, using dummy void functions.  We need a policy
statement on inline (particularly member) functions, because they 
may lock us into particular struct layouts, no matter how careful 
we've been otherwise.

Nathan Myers
ncm at cantrip dot org


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]