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

Subject: Re: [Boost-users] custom allocators Re:pool_alloc
From: Filip Konvička (filip.konvicka_at_[hidden])
Date: 2010-03-19 18:41:45

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"
> <filip.konvicka_at_[hidden]>
> To: <boost-users_at_[hidden]>
> 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_at_[hidden]
>>>> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>>
>>
>> _______________________________________________
>> Boost-users mailing list
>> Boost-users_at_[hidden]
>> http://lists.boost.org/mailman/listinfo.cgi/boost-users