Design Issues
Prev | Chapter 20. The mt_allocator | Next

## 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.

Prev | Up | Next
Chapter 20. The mt_allocator | Home | Implementation