From: Ryan Gallagher (ryan.gallagher_at_[hidden])
Date: 2006-04-25 02:00:25
Matias Capeletto <matias.capeletto <at> gmail.com> writes:
> This is where the path concept will allow some magic. IMO the 'most'
> important property of the having a path class is the orthogonality
> that it introduce. Iterate with a path in a ptree and constructing a
> path are now two clearly separated process.
I have to agree with this statement. I've been thinking that path should be
a separate concept. Instances of the concept could even be worked on
I really see building a path much as you would build an expression template
to be evaluated when invoked by the getter. I've been thinking something like:
ptree ptree::get(Path const& p)
return eval(p, *this);
One good concretization of this concept would be an xpath-like implementation.
Some of the additions for this would be quite similar to what you mentioned in
a previous thread with your overload of operator%. I would instead be
interested in seeing operator implemented in this way since this is more
xpath-like and IMHO easier to read. (Disadvantage is precedence.) That is
xpath_expression& xpath_expression::operator(where_expression const&).
where_expression would be very similar to lambda. Based on your example
from the other thread:
data.get((p / "log")[_1 / "text" == "error1"] / "checked" + "id");
Following along the xpath and xslt I'd also like to see grouping. In my mind
there should be an accessor to get the group resulting from evaluating the
xpath expression. A group would be modeled by a view of ptree nodes.
= tree.get((xpath("p") / "log")[_1 / "text" == "error1"] / "checked" + "id");
BOOST_FOREACH(ptree& result, result_group)
cout << result.data() << " ";
would output: "0 2".
Just my 2c,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk