• Create Account

## pool allocator

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

3 replies to this topic

Posted 26 September 2012 - 06:29 AM

Hello again, I have another query about custom allocators.

I've read that allocators of the same type are required by the standard to be able to
deallocate the memory that another of its type has allocated. This presents a problem when trying to implement
a memory pool based allocator (or variation thereof) seeing as I would like each pool allocator to manage its own
memory block, the size of which supplied by a template parameter. Something along the lines of

template <typename T, std::size_t Blocks>
class pool_allocator ;


But of course allocators of the same type would not be able to deallocate memory of other instances of the same
type of pool class.

I decided try and make the data members static, _blocks, and _size for now since I haven't really fleshed out how this is going to work. and then do something like this:

inline pool_allocator( ) noexcept {
T* __Tmp = reinterpret_cast<T*>(::operator new((Blocks + _size) * sizeof(T)));
std::uninitialized_copy(_blocks, _blocks+_size, __Tmp); // may not be necessary because most pools will be constructed at the beginning of the program, but it doesn't hurt runtime to have it in there if this is the case.
_blocks = __Tmp;
_size += Blocks;
}

// ...
// static member initialization
template <typename T, std::size_t Blocks> T* pool_allocator<T, Blocks>::_blocks = nullptr;
template <typename T, std::size_t Blocks> std::size_t pool_allocator<T, Blocks>::_size = 0;


It would be better if I could get the summation of all pool allocator Blocks at compile time but I see no way to do this at the moment - ideas anyone?

...

There was something else I wanted to say as well but it escapes me at the moment.. It'll come back.
Anyway, how would I deal with fragmentation in the most efficient manor possible while still maintaining contiguous blocks of memory that arrays allow for? some things may be deallocated from the middle of the memory block and the only way I can see is to keep a sort of queue of pointers to free space in memory but this is a terrible solution for obvious reasons.

I'm not entirely sure my approach will work in the end, but there is little to go by on the internet that I've found

Edited by roadysix, 26 September 2012 - 06:39 AM.

### #2SiCrane  Moderators

Posted 26 September 2012 - 07:14 AM

I've read that allocators of the same type are required by the standard to be able to
deallocate the memory that another of its type has allocated.

No, memory allocated by a allocator A can be deallocated by allocator B only if A == B is true. If they aren't equal to each other, they're not required to be able to deallocate each other's allocated memory. See section 20.1.5 of the C++03 standard or 17.6.3.5 of the C++11 standard.

Posted 26 September 2012 - 08:27 AM

I've read that allocators of the same type are required by the standard to be able to
deallocate the memory that another of its type has allocated.

No, memory allocated by a allocator A can be deallocated by allocator B only if A == B is true. If they aren't equal to each other, they're not required to be able to deallocate each other's allocated memory. See section 20.1.5 of the C++03 standard or 17.6.3.5 of the C++11 standard.

I don't have the standard documentation available to me nor do I know where to get it. What you have said is essentially what I mean but the problem is that allocators of the same type are required to return true from A == B (or so I read somewhere) I am probably wrong, if so does this mean I can implement the comparison operators normally?

### #4SiCrane  Moderators

Posted 26 September 2012 - 08:46 AM

No, neither of the C++ standards require that operator== return true for any two allocators of the same type. Again, see the above mentioned sections of the relevant standards. Copies of both can be purchased from your national standards body (e.g. ANSI for the US). A dead tree edition of the C++03 standard is available from Wiley (ISBN-13: 978-0470846742). There are also draft versions of both standards available as PDFs all over the internet, which are more or less identical to the actual standards.

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.