Yes. "Memory pools" are useful in many situations. The bad news is that I'll need to drag you through the mire of how it acts before we talk about all the uses.
Firstly, recall that a memory allocator is simply imagined to return uninitialized bits of memory; this is not supposed to generate "objects." Particularly, the memory allocator is not imagined to set the virtual-pointer or any other part of object, since that is the job of the constructor that runs after memory allocator. Beginning with a simple memory allocator function, allocate(), you would employ placement new to build an object in that memory. In other terms, the following is equivalent morally to new Foo():
void* raw = allocate(sizeof(Foo)); // line 1
Foo* p = new(raw) Foo(); // line 2
Supposing you've utilized placement new and have survived the above two lines of code, the after that step is to turn your memory allocator in an object. This type of object is called as a or a "memory arena." Or "memory pool" .This allows your users have more than one "pool" or "arena" from which memory shall be allocated. Each memory pool objects will allocate a big chunk of memory via some specific system call (for example. shared memory, persistent memory, stack memory, etc.; ), and will dole it out in little chunks as required. Your memory-pool class might look something as:
class Pool {
public:
void* alloc(size_t nbytes); void dealloc(void* p); private:
...data members used in your pool object...
};
void* Pool::alloc(size_t nbytes)
{
...your algorithm goes here...
}
void Pool::dealloc(void* p)
{
...your algorithm goes here...
}
Now one of your users might have a Pool called pool, from which they could allocate objects such as