Question

Why is the boost::fast_pool_allocator built on top of a singleton pool, and not a separate pool per allocator instance? Or to put it another way, why only provide that, and not the option of having a pool per allocator? Would having that be a bad idea?

I have a class that internally uses about 10 different boost::unordered_map types. If I’d used the std::allocator then all the memory would go back to the system when it called delete, whereas now I have to call release_memory on many different allocator types at some point.
Would I be stupid to roll my own allocator that uses pool instead of singleton_pool?

thanks

Answer 1

It’s difficult for an allocator to have state, since all instances of an allocator had to be ‘equivalent’ to be used by the standard library (at least portably).

From 20.1.5/4 “Allocator requirements”:

Implementations of containers described in this International Standard are permitted to assume that their Allocator template parameter meets the following two additional requirements beyond those in Table 32.

• All instances of a given allocator type are required to be interchangeable and always compare equal to each other

It then goes on to say:

Implementors are encouraged to supply libraries that can accept allocators that encapsulate more general memory models and that support non-equal instances. In such implementations, any requirements imposed on allocators by containers beyond those requirements that appear in Table 32, and the semantics of containers and algorithms when allocator instances compare non-equal, are implementation-defined.

So an implementation can be written to allow non-equivalent allocator instances, but then your allocator is dependent in implementation-defined behavior.

See this other SO answer for some additional details (and it looks like I need to tend to some promised updating of that answer…)