Re: stl_vector.h?!? (Re: [libstdc++] PATCH: STL allocator cleanup, part 1)

[Matt Austern <austern at apple dot com>]

On Dec 19, 2003, at 12:57 PM, Benjamin Kosnik wrote:

> I think the ext allocators can move to standard-conforming allocator
> style immediately, right? That work can proceed independently of the
> _Alloc_traits removal.

I think so, yes.

> Yes.... have you given any thought to a way to configure the default
> allocator? There was some hand-waving about this awhile back. I still
> don't see a good way to do this.
>
> I bring this up, because I'm not convinced that __pool_alloc is really
> the best solution for a default allocator for thread-enabled, SMP
> systems.

I haven't really thought about configuring for alternate allocators, no.
My impression is that most people just use the equivalent of our
__new_alloc, and that pool-based schemes are pretty rare.

I suppose "configuring" could mean one of two things: set up a
particular allocator at library build time (perhaps using target-
specific defaults), or give users a way to build their applications
with alternative allocators by changing nothing but a -D flag or a
link flag.

It should be easy enough to put in a configuration macro in
<memory> to choose between a simple new-based allocator
and a pool allocator.  On the other hand, I'm tempted to just
punt on this feature and let people who need alternative allocators
provide them for containers.

(You're right, it's not obvious that a pool-based solution is best.
It does have the virtue of space efficiency, though.  ::operator new
needs to keep track of the size of the blocks it allocates, but
std::allocator doesn't)

			--Matt