status on the allocator work

[Matt Austern]

On Dec 22, 2003, at 9:34 PM, Benjamin Kosnik wrote:

> Matt correct me on this if I'm wrong.
>
> Remaining container conversions:
>
> rope
>
> Remaining on the allocator classes:
>
> 1) Remove __simple_alloc, _Alloc_traits, all non-standard bits.
> (including support for old-style allocators from the debug mode.)
>
> 2) Fix or remove  __debug_alloc.
>
> 3) Fix __mt_alloc ctors, consolidate initialization in ctors, convert 
> to
> using new, try to remove some of the impossibly gross casting! It seems
> to me that a lot of the internal data types could have ctors/dtors that
> self-increment...
>
> 4) Convert __pool_alloc
>
> 5) Find better names for __pool_alloc, __mt_alloc, new_allocator. In
> general, it looks like 3.4 is going to be a complete break from 
> 3.[2,3].
> This shouldn't be a surprise: it's been something that has been
> documented and planed for months now. We should feel free to come up
> with something good, and as clean as possible. Emphasis on clean.....
>
> Then, I'm suggesting that the std::allocator be either __mt_alloc or
> __pool_alloc, configurable. Before we make a decision, I'd like to 
> check
> in to the performance testsuite specific MT benchmarks. (This is
> pending.) That way, data for different systems can be gathered.

I think all of that is right, but a few additional comments:
  (1) Your #1 should come later in the list!  We can't do it until we've
      done most of the other things in the list.
  (2) One additional piece of work: remove the gratuitous templatization
      of the various ext allocators (I'm thinking of the 'inst' template
      parameter, which is entirely artificial), and move things we don't
      want to be inline into .cc files.  Also, as long as we're cleaning
      up mt_alloc, might as well change it to use ::operator new and
      ::operator delete instead of malloc/free.  No reason not to.
  (3) We haven't decided on a strategy for making std::allocator
      configurable, or on exactly what configurability means.
      (Configurable at library build time? At application build time?)
      We should discuss this, because it might affect the interfaces
      we choose for the ext allocators.

			--Matt