Boost C++ Libraries: Ticket #5806: Property tree supporting custom allocators such as the boost pool ones

Sebastian Redl — Tue, 23 Aug 2011 11:55:39 GMT

PTree's design (which predates my stewardship) makes custom allocators tricky. Stateless allocators can be done without too much trouble, but stateful allocators are inefficient (needs an allocation and refcounting) and complicated to implement (since you don't want to penalize the stateless case).

vivien.millet@… — Tue, 23 Aug 2011 12:36:48 GMT

I don't get it :) how can it be penalizing if the user can choose it's own allocator through template instanciation like STL does, which can be either stateless or stateful ones (eventually providing a default one if user don't provide it) ?

I've seen in the ptree_implementation.hpp somewhere in the constructors :

: m_Children(new typename subs::base_container).

Correct me if i'm wrong but is this couldn't be replaced by :

m_Children = _Alloc::rebind<typename subs::base_container>::other::allocate();

new (m_Children) typename subs::base_container;

"_Alloc" being the template argument we add to

basic_ptree<class K,class D,class Comp,class _Alloc = std::allocator<any_type_since_we_use_rebind>>

regards.

anonymous — Tue, 23 Aug 2011 13:00:35 GMT

I made a mistake, allocate() method in std::allocator isn't static. But we could imagine storing an allocator object in the basic_ptree still using rebind, or providing a default allocator using static methods which invoke basic malloc and free.

regards.

Sebastian Redl — Tue, 23 Aug 2011 13:40:18 GMT

In STL containers, there is a container object which owns all the values inside. An STL container does not contain children of its own type.

A PTree node contains children of its own type. You can obtain a reference to any subnode of the tree. There is no container that owns all nodes in the tree; instead every node owns its children, and the root is implicitly the node that isn't owned by any other. There are no up pointers in the tree.

Because all nodes have the same type and no node can access its parent (and thus neither any other ancestor), there is no authoritative place to store a stateful allocator. This means that *every* node would need a copy or at least reference to a stateful allocator.

As I said, supporting stateless allocators wouldn't be much trouble. (Still would be some trouble - PTree has a lot of template arguments as it is.) Still, with C++11 and its new allocators around the corner, I feel this is the worst time to add allocator support possible.

vivien.millet@… — Tue, 23 Aug 2011 14:53:29 GMT

I understand more the problem now, thanks. The best would be to accept only static method allocators such as boost::fast_pool_allocator, but if it's not in your plan to modify custom allocation right now, i understand. I think i will do my own modified implementation to fit my project if i can, waiting for C++11.

Do you know exactly what C++11 will change concerning allocators which make you prefer not modifying any code relative to them ?

owner changed

Sebastian Redl — Wed, 21 Jan 2015 13:14:19 GMT

owner changed from kaalus to Sebastian Redl