What C++ std compliant custom allocators are available?

Question

I would like to use some C++ std compliant memory management in form of a class derived from std::allocator, but able to allocate chunks of memory and releasing & freeing them in smaller parts. I only found boost::pool, but this is not std compliant in the above sense. Is there anything more useful around or do I have to code this myself?

(Note that the std::allocator is often useless for allocating many small objects, i.e. when using a std::list.)

EDIT to clarify.

Say, I want to use a std::list of many small objects, then implementations of std::allocator which allocate each object using ::new cause significant overhead in run time (but also memory I think). It is much more efficient to allocate big chunks of objects and hand them out one by one. For this, I need a std-compliant allocator (doesn't need to be derived from std::allocator, but must implement the same concept) that can be used with any std library container and provides the required memory management, ideally allowing me to tell it how many objects I am likely to individually allocate.

Answer 1

GCC provides a few extension allocators as alternatives to std::allocator.

You haven't really said what your requirements are, so it's not possible to say if any of them would be suitable for you.

Edit following OP's edit:

Say, I want to use a std::list of many small objects, then implementations of std::allocator which allocate each object using ::new cause significant overhead in run time (but also memory I think).

Why also memory? The overhead of additional pointers in each std::list node will be present whether the memory comes from new or a custom allocator. Do you just mean the bookkeeping done by the heap to track all the small allcoations?

It is much more efficient to allocate big chunks of objects and hand them out one by one.

Have you measured it?

If you don't want the overhead of allocating lots of separate nodes are you sure std::list is the right container? What about vector or deque?

boost::stable_vector is still node-based but has less per-node memory overhead than std::list.

A boost::flat_map<int, T> isn't node-based and could be used instead of std::list<T>

Allocators are tricky and not always the best answer to (real or perceived) problems.