Re: [Boost-users] custom allocators Re:pool_alloc

On 19.3.2010 20:22, Eric Whitcombe wrote:

So.. have you modified STL code? Or is boost::pool some how able to reimplement std::set (or any STL container) node alllocation code? That would be quite a trick because, all else being equal, if all you are doing is providing your own allocator to an STL container you will not change how the container allocates it's internal implementation data structrures. You will only be changing how elements are allocated.

Please don't top-post. Of course I did not modify the STL. As Steven is pointing out, containers use rebind to get the allocators they need. Usually, the node contains the user's type plus some node information (like a pointer or two, or color etc.). What I did is better done with a non-singleton allocator that consumes memory of one or more local 'pools'. You allocate the container itself within this memory (using placement new or something similar), and you provide the container with an allocator that also takes memory from there. Then you just leave the scope, the pool(s) disappears and the container plus all the data just disappears with them, no destructors called. So this is only safe if you know what you are doing - you should only store ints or something that does not need their destructors called (for example in order to prevent memory leaks, which you would get with strings). I guess this is in fact what the OP wishes to do (he's surprised that the singleton pool does not sometimes release memory to the system, which is in fact the expected behavior). For reference, this is the message on the comp.lib.gecode.user newsgroup where I posted the code: http://article.gmane.org/gmane.comp.lib.gecode.user/2187/match=allocator Actually I think it's part of Gecode distribution now (see www.gecode.org). Also see http://www.gecode.org/doc-latest/reference/group__FuncMemAllocator.html HTH, Filip

----- Original Message ----- From: "Filip Konvicka" To: Sent: Friday, March 19, 2010 2:09 PM Subject: Re: [Boost-users] custom allocators Re:pool_alloc

...

...

Sorry, if this is a little late to be helpful but I thought I'd add this for historical purposes for anyone looking at this thread to deal with their own problem. All STL containers use allocators to allocate and initialize the memory to store the _elements_ in the container not the node structure. The containers definition of the data structures that support the implentation details are purely internal. The allocator interface is paramterized on the type of the container element.

In fact what I've done once is to have both the set object and the nodes allocated in a kind of pool, and then just not call the destructor (just have the set and its nodes disappear with the pool/pools). THAT is a speed-up (otherwise a set gets years to destroy).

Filip

...

...

B Hart wrote:

...

Sorry, I don't get you...as I understand the pool is a singleton, and once out of scope I would assume all the memory for the set is released back to the OS. Therefore what is the purpose of release_memory()...maybe I don't understand pool. And then "internal node type"...what is that?

Set is implemented using a binary search tree. set<int> doesn't actually allocate ints, it allocates a struct that probably looks something like:

struct Node { int value; int color; Node * left; Node * right; Nonde * parent; };

pool_allocator uses separate singleton pools for each size of element that it needs to handle.

In Christ, Steven Watanabe

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users