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