Matias Capeletto wrote:
Something like this may work...
ptree data; ptree::path p;
data.put( p / "debug" / "info" / "testfail" , "somefile.hpp" );
If we're going down that road, Shouldn't
data.put( p/"debug/info/testfail/somefile.hpp" );
be made to work, too?
I'm really not seeing the introduction of a path class as an improvement. What was wrong with the two traversal mechanisms already in the library? Combine it with a more intelligent path grammar that autodetects alternative separators as in
"debug.info.testfile" // using . "/debug/info/test.file" // uses /
and all is well.
Nothing is wrong with the library now, and adding the path class will still allow you to write the code you post and with better performance (you may want to see how is implemented now in the ptree_implementation.hpp). This is one of the reason Marcin said that he is going to considered it. This abstraction opens the door to a more general aproach to especifing path. We already discusse that we can use it to give indexing support and permitted to embed variables directly in the path without the need for something as ugly as: "debug." + infoName + ".testfile" IMO this code is more error prone and innefinient than p / "debug" / infoName / "testfile"