[boost] property tree and default translator_type

From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2008-05-23 20:29:38

Hi,

I've been using property_tree for quite a while now, and I think it's
a very useful library, many thanks to the authors for their work!

I'm wondering if it's possible to refactor it a bit, so that users can
configure it to be more lightweight? In it's current form it pulls in
quite a lot dependencies, where many are used only by the default
template translator parameter (which is std::stringstream based);
If I supply a translator of my own I won't get rid of the includes in
ptree.hpp. Wouldn't it be better that users include
property_tree/translator.hpp when they need to parse data from the
tree? In my experience I often need to manipulate the property_tree,
but without doing and type conversion. Such code would compile faster
with the translator left out.

Pushing it a bit further, I don't think the translator should be a
class member template at all, since it has nothing to do with the
contents of the tree.
Parsing of data is done on a 'use-case' basis, meaning that different
code has different requirements on the parser, even if it reads the
data from the same tree.
With the current design I cannot choose to parse an int (say) using
boost.spirit at one location, and the default stringstream parser at
another, unless instantiating a new basic_ptree<...> type.
I am of course free to not use the translator and instead access
data() directly and pass it to the parser of my choice, but then I
need to reimplement some parts of the get_value and get_optional which
are very useful as they are now (and probably more carefully written
than I would come up with).

I would prefer the translator to be a template parameter to the
get()/get_xxx() functions instead. This would probably give faster
code for the end-user too,since they are encouraged to instantiate a
translator before parsing values from the tree. The default translator
would in this case reuse its internal stringstream object, instead of
recreating one for every read.

Something like this:

property_tree::ptree pt;
property_tree::translator t;
pt.get_value<int>(t);
pt.get_value<float>(t);
pt.get_value<int>(my_custom_number_parser());

The above would create only one stringstream, compared to:
property_tree::ptree pt;
pt.get_value<int>(); // stringstream()
pt.get_value<float>();  // stringstream()
// I cannot use my_custom_number_parser here at all, unless creating
some kind of composite translator type, which isn't easy when dealing
with polymorphic function objects.

Thoughts on this, anyone?

/ Christian