Hi Christian,
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?
That's definitely possible to do, althought I'd rather keep the default ptree.hpp file including everything the tree needs to work in the default way (the most common case is to use default translator / default path). There might be a separate file that pulls only the ptree class without any translators or other auxiliaries. Ptree must be simple to use, and requiring all users to include many files and create many objects before they can get to the values is not good.
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.
Ptree needs a default translator, so that users do not have to specify their own every time they try to extract something from the tree. The default translator type is a template argument of the ptree class. Unfortunately you are right, the current implementation enforces use of the default translator, because there are no overloads for get functions that take different translator type than the default. You can only specify a different instance of the default translator. This is something that got overlooked and needs fixing.
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.
In your case the parsing is done on a case-by-case basis, but IMO most users don't use property tree that way. They are fine with the default translator (they may not even know it exists under the hood). I wouldn't take it out, just add the overloads that allow you to specify a different one.
I would prefer the translator to be a template parameter to the get()/get_xxx() functions instead.
Yes, that's what I mean by adding overloads to get/put functions that take different translator types. But there's also path_type (for traversing paths in the tree) that some users might want to configure in the same way as the translator. Than means we have to add 4 combinations of overloads per each get function (and we already have several of these). I'm not sure if it's possible to avoid all this messy overloads without default function template arguments (due with C++0x)? Marcin