Re: [boost] [Boost Review] Property Tree Library

From: Ivan Vecerina (ivec_at_[hidden])
Date: 2006-04-21 04:36:55

"Andy Little" <andy_at_[hidden]> wrote in message 
news:e2a1p5$5he$1_at_sea.gmane.org...
:
: "Andy Little" wrote
: >
: >Did you consider a generic tree design? If so
: > why did you reject it in favour of this one?
:
: Just to refresh... The above is the most interesting and yet unanswered 
question
: about property tree for me. Am I missing something? Is this a silly 
question? Is
: it too trivial to answer?

I would agree that this is an interesting point.
 - ptree integrates too many member functions that really should be
   non-member utilities  (e.g. path solving, value<->ptree conversions)
   Fixing this is a must IMHO, I wouldn't want to accept another
   std::string like beast (too much built-in, yet never enough, so you
   end up with an inconsistent mix of member & non-member interfaces)

 - in some ways, since it is already all-templated, maybe it could be
   made even more general (e.g. boost::any based values or nodes?)

On the other hand, loading a DOM-like tree structure into memory,
and being able to manipulate it, is I think quite a common need.
By design, it also supports I/O to a variety of formats, which
is also very nice.

boost::serialize is nice, but it goes straight from binary object
to external stream (or inversely), with no intermediate
representation.
And maybe there lies an interesting interface point:

Should ptree be a potential target / archive type for boost::serialize?
>From this perspective, what feature set would we want to see
in the ptree structure ?

-- 
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form