property tree and default translator_type
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
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
I agree that simplicity is a good selling point, but reducing compile times to reasonable levels is more important IMO. When using heavy libraries like fusion or spirit there are dozens of different files that I always need to include, and I appreciate this design very much. Problem is that if compile times drops and there's no way to work around it, there's no other option than to discard the library completely, or spend a lot of time wrapping it.. Other libs have chosen a convenience header that brings everything to make the default behaviour to work. I don't see why this can't be done with property_tree.. As ptree looks now one would need to include detail/ptree_implementation.hpp to avoid the inclusion of things one do not need, and getting things from detail/ is always a bad idea I think.. 2008/5/24 Marcin Kalicinski <kalita@poczta.onet.pl>:
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (2)
-
Christian Holmquist -
Marcin Kalicinski