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 separately. 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: template<typename Path> 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. For: <p> <log><text>error1</text><checked id=0>foo</checked></log> <log><text>warning</text><checked id=1>foo</checked></log> <log><text>error1</text><checked id=2>foo</checked></log> <log><text>error1</text><unchecked id=3>foo</unchecked></log> </p> group result_group = 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, -Ryan