From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2008-05-23 20:29:38
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:
The above would create only one stringstream, compared to:
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk