Re: [boost] property tree and default translator_type

From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2008-05-28 17:51:37

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_at_[hidden]>:
> 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
>