On 4/24/06, Jeff Flinn <TriumphSprint2000@hotmail.com> wrote:
Thorsten Ottosen wrote:
Matias Capeletto wrote:
If we get the path into ptree we can overload other operator to support this type of path (we can not overload operator[]... because of precedence issues :( someone nows a way we can still use it?, the sintaxis will be very nice. As i see it, the only the choosen operator must have the same priority, see the examples, so we have only have * and % ).
Something like this may work...
ptree data; ptree::path p;
data.put( p / "debug" / "info" / "testfail" , "somefile.hpp" ); data.put( p / "debug" / "info" / "testfail" , "otherfile.hpp" ); data.put( p / "debug" / "info" / "testfail" , "wer.hpp" );
data.set( p / "debug" / "info" / "testfail" %2 , "file.hpp" ); // we use set!
some simple function would allow you to write
data.set( p / "debug" / "info" / "testfail" / at(2) , "file.hpp" );
Yes, it is possible, i still like the % more, i want that the difference from indexing(%) and 'getNextChild' (/) can be read directly from the code.
or we might say
data.set( (p / "debug" / "info" / "testfail")[2] , "file.hpp" );
This have the drawback that we can not index internal nodes and continue with a path... That is the reason IMO the two operators must have the same precedence level. And it is just beatifull to see that there are two operators (% and *) that fullfill this requierement for the operator/. I think that something like this data.get( p / "log"%4 / "info" / "time" ) is very self descriptive. If there are less than 5 childs with the tag "log" this will generate the result you choose when pick the dessired get function (throw,optional,default)
or perhaps
data.set( p / "debug" / "info" / "testfail[2]" , "file.hpp" );
This is ok... but if we give the option of using "log.info.time" or p / "log" / "info" / "time" then we must consistenly give an option for indexing too.. and in the case whe choose operator% or * i think it will be more clear if we use the following notation... "log%3.info.time" ( now that i see it in the screen "log[3].info.time" is somewhat more nice to the view, what do you think?)