I\'m going to build a custom allocator, preallocating a big block (array) for storing N
elements of some class T
, and then just increase an in
You are on the right track.
One irritating details is that copies of allocators must compare equal, even converting (rebound) copies. Comparing equal means they can deallocate each other's pointers. So a container such as std::list<int>
will rebind your_alloc<int>
to your_alloc<node<int>>
and then construct a your_alloc<node<int>>
using a your_alloc<int>
. And technically your your_alloc<node<int>>
has to deallocate a pointer allocated by your_alloc<int>
.
Here is my attempt to meet this requirement. Feel free to copy/modify/abuse this code. My intent is to educate, not become the world's allocator supplier (which wouldn't exactly be lucrative anyway :-)).
This example takes a slightly different approach to alignment: I happen to know that on my platform of interest (OS X, iOS) that malloc
returns 16 byte aligned memory, and so that's all my custom allocator needs to return. You could change that number to whatever is appropriate for your system.
This hardwiring of alignment means that a single pool can safely supply several allocator<int>
and allocator<node<int>>
, as they are all 16-byte aligned (and that's enough). And it also means that copies, even converted copies, can detect when the pointer is pointing into the buffer, since copies all share the same buffer.
Said slightly differently, the C++ committee has effectively specified that allocators are reference types: copies are equivalent and point to the same memory pool.
You can get away with cheating, using memory pools actually embedded into the allocator, but only with some containers on some implementations, and you can't back that up with a quote from the standard.