This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3] allocator switches
- From: Felix Yen <fwy at alumni dot brown dot edu>
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Wed, 28 Jan 2004 17:39:16 -0500
- Subject: Re: [v3] allocator switches
> I'm not quite sure about this.
>
> We've got to support both std::allocator, and ext allocators that
can be
> used as _Alloc template parameters.
>
> Can this be accomplished with the above design? I'm uncertain.
It depends on how literal this support must be. In the approach I
sketched, there would be two allocator interfaces, the standard one and
a minimal one that probably has just two methods, allocate() and
deallocate(). For the purpose of discussion, I'll call objects that
have this second interface GNU-style allocators or GSA's, and assume
that all the allocators in /ext are modified accordingly. Now
std::allocator becomes something like:
template<typename _Tp>
class allocator : public __gnu_cxx::Allocator<_Tp,
__gnu_cxx::__default_alloc>
{/*possibly empty*/};
The parameter list depends on how allocators are configured. In my
example, the new Allocator template hypothetically encapsulates all
references to GLIBCXX_FORCE_NEW, so there's no parameter for that
information. In real life, there would be a second GSA parameter to
support large requests (e.g. buffer allocation), and the template would
encapsulate the logic to determine which GSA to use based on request
size and a configuration technique to be determined (another
environment variable?). This second GSA would probably be
new_allocator, but users may want to use malloc_allocator or
debug_allocator instead.
In this approach harnessing another /ext (GNU-style) allocator entails
defining another template, e.g.
template<typename _Tp>
class sgi_allocator : public __gnu_cxx::Allocator<_Tp,
__gnu_cxx::__sgi_alloc>
{/*possibly empty*/};
These alternatives would be defined in another namespace, and could be
used as _Alloc template parameters. I'm not sure if that constitutes
support, but the approach is technically feasible. It's also quite
radical, which is why I placed it "in the long run," but the payoff is
substantial. In this approach, a lot of allocator complexity is
implemented by ordinary classes instead of template classes, thereby
simplifying maintenance and facilitating custom/future allocator
development. In fact, these classes can just wrap calls to a pair of
functions defined in some namespace.
> The hope is that the default allocator will just be known as
std::allocator.
> End of confusion, period.
If you buy the idea of separating an allocator's implementation into
the standard stuff and an underlying GSA, while offering a variety of
these GSA's and a way of composing standard allocators from them, then
one of these GSA's must be the default.
> Then, the ext allocators will actually be named something that makes
> sense via inspection. Of __mt_alloc and __pool_alloc, __pool_alloc is
> a bit better in this regard.
Default Allocator may be just as bad; they're all redundant in some way.
The question is whether users care more about how these things work, or
what they are. Many allocators use some sort of pooling technique, and
many are designed to support multithreaded applications, so focusing on
these aspects can lead to naming conflicts. On the other hand, SGI
Allocator refers to the allocator's legacy status, thereby hinting that
it's probably not the one people will want to use. __pg_alloc (Pretty
Good Allocator) is cute. Maybe __so_alloc (Small Object Allocator) ...
Felix