Re: [libstdc++] PATCH: STL allocator cleanup, part 1

[Benjamin Kosnik <bkoz at redhat dot com>]

>I mentioned a few weeks ago that I was working on cleaning up the use 
>of allocators in the STL part of libstdc++.  This is a patch for the 
>first part of that work, to give people a better idea of where I'm 
>planning to go.  This part is complete in itself, and I've tested it on 
>Linux (I've verified that it doesn't break the libstdc++ or libjava 
>build on Linux and that it doesn't introduce libstdc++ regressions), so 
>first of all: OK to commit to mainline?

I'm a big fan of this cleanup, and hope that it goes in quickly. I've
tested versions of this patch on linux and can also verify your results. 

This has been a long time in coming: thanks again for making it happen.

>Specifically, the various stages of this work:
>  1. This patch: change vector<>, deque<>, list<>, and the four hash 
>containers so that they no longer use _Alloc_traits and they no longer 
>have alternative base classes depending on whether or not the allocator 
>is instanceless.  Instead, just inherit from the allocators and rely on 
>the empty base class optimization for instanceless allocators.  It's 
>safe to rely on that optimization, because it's written into our ABI.  
>Also fix previously hidden bugs in demangle.h (see below).
>2. Do the same thing for the remaining containers: vector<bool>, the 
>four standard associative containers, rope, and slist.  (If anyone 
>would like to volunteer to do rope, I'd appreciate it.)
>3. Remove _Alloc_traits, and remove all support for the old 
>pre-standard SGI allocator interface.
>4. Some of the internals of allocator<> should always have been 
>declared out-of-line, in a .cc file.  The reason Hans and I didn't do 
>that back at SGI was that we wanted it to be possible to install STL as 
>headers only, so we artificially made some things templates just so 
>they could go in headers.  This goal is now irrelevant.  So: get rid of 
>the artificial templatization in stl_allocator.h, and put things that 
>belong in a .cc file in one.

I think all of these are very worthwhile goals. I'm currently in the
middle of other work, but will be available to help this effort as soon
as I'm done. It looks like Paolo will help with rope, which is welcome
news indeed.

-benjamin