From: Ivan Vecerina (ivec_at_[hidden])
Date: 2006-04-21 04:36:55
"Andy Little" <andy_at_[hidden]> wrote in message
: "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
: about property tree for me. Am I missing something? Is this a silly
: 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
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