Design Issues

Overview

There are three general components to the allocator: a datum describing the characteristics of the memory pool, a policy class containing this pool that links instantiation types to common or individual pools, and a class inheriting from the policy class that is the actual allocator.

The datum describing pools characteristics is

  template<bool _Thread>
    class __pool

This class is parametrized on thread support, and is explicitly specialized for both multiple threads (with bool==true) and single threads (via bool==false.) It is possible to use a custom pool datum instead of the default class that is provided.

There are two distinct policy classes, each of which can be used with either type of underlying pool datum.

  template<bool _Thread>
    struct __common_pool_policy

  template<typename _Tp, bool _Thread>
    struct __per_type_pool_policy

The first policy, __common_pool_policy, implements a common pool. This means that allocators that are instantiated with different types, say char and long will both use the same pool. This is the default policy.

The second policy, __per_type_pool_policy, implements a separate pool for each instantiating type. Thus, char and long will use separate pools. This allows per-type tuning, for instance.

Putting this all together, the actual allocator class is

  template<typename _Tp, typename _Poolp = __default_policy>
    class __mt_alloc : public __mt_alloc_base<_Tp>,  _Poolp

This class has the interface required for standard library allocator classes, namely member functions allocate and deallocate, plus others.