Property tree supporting custom allocators such as the boost pool ones

[vivien.millet@…]

I'm currently working on a c++ extension based on custom allocators and i wanted to use property_tree in my serialization section as it seems very well designed, but i'm stuck with the fact that basic_ptree doesn't allow an allocator type to be passed as argument. It would be very nice to add custom allocation to property_tree so that we can : first customize internal ptree allocations and then use customized version of STL with it. regards.

[Sebastian Redl]

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@…]

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]

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]

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@…]

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 ?