This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
std::allocator and underlying allocators
- From: Matt Austern <austern at apple dot com>
- To: Benjamin Kosnik <bkoz at redhat dot com>, libstdc++ <libstdc++ at gcc dot gnu dot org>, Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- Date: Sun, 25 Jan 2004 18:15:28 -0800
- Subject: std::allocator and underlying allocators
- References: <200401232018.i0NKIGKB035464@latour.rsch.comm.mot.com>
On Jan 23, 2004, at 12:18 PM, Loren James Rittle wrote:
I will state MHO. Any allocator, to be made the default, should
support the above construct internally. The reason is that people
will compile their application normally against the default allocator.
We want to ensure that people can always disable memory caching within
the library. Also, many people have tools which directly hook to
malloc/new, free/delete to look for programming errors. The use of a
pool hides various application-level testing developers could
otherwise do.
This leads to another interesting question. Right now,
std::allocator still uses the concept of an "underlying"
SGI-style allocator. It's set to be __pool_alloc<true, 0>
by default, with the idea that you can easily modify the
source to make it something else.
Well, there are three problems with that. First, we've
removed every trace of the old SGI-style interface
everywhere else, so why keep it around here? Second,
it's no longer true that you can easily replace
__pool_alloc<true, 0> with another allocator, because
there aren't any alternatives with the same interface.
Third, the second template parameter for __pool_alloc
("inst") is entirely artificial and should be removed.
So given that std::allocator should be fixed, we've got
two alternatives.
(1) Get rid of the notion of an underlying allocator, and
just implement allocator on its own. In principle I like
this idea; it maintains a clear separation between the
standard and extended parts. We'd have to decide
which technology we want to use for the default, of
course: the existing pool allocator, or the bitmpaped
allocator, or whatever.
(2) Continue to use the idea of an underlying allocator,
but use a standard interface instead of the SGI one.
So we'd have to fix pool_allocator.h to provide a
standard interface, and then change allocator.h so
that it uses a standard interface. Mildly ugly, but quite
doable.
Thoughts?
--Matt