"Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message news:e2a1p5$5he$1@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