Jump to content

  • Log In with Google      Sign In   
  • 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.

  • You cannot reply to this topic
3 replies to this topic

#1 roadysix   Members   -  Reputation: 290

Like
0Likes
Like

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.


Sponsor:

#2 SiCrane   Moderators   -  Reputation: 9131

Like
0Likes
Like

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.

#3 roadysix   Members   -  Reputation: 290

Like
0Likes
Like

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?

#4 SiCrane   Moderators   -  Reputation: 9131

Like
0Likes
Like

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.



PARTNERS