Boost logo

Boost Users :

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


> 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 list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net