This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]