From: Matias Capeletto (matias.capeletto_at_[hidden])
Date: 2006-04-21 22:02:50
> Additionally the library should have a get/put-style member function to
> delete an existing property. It obviously has erase, but it does not work
> with paths. We would end up with get/set/put/del(?), and the picture would
> be, hopefully, complete.
That is it! I really like the new set/del, seems fairly easy to learn and solve
the bool argument problem, adds a lot of functionality too.
I have to propose only one more feature, before the picture is complete.
If you look in this thread, someone ask for something like
"debug.info.testfail[2]" for access repeated tags
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!
And we can use it in the middle too, if we have...
-------------------------------------
<logFile>
<log>
<time>10:13</time>
<what>cant find path</what>
</log>
<log>
<time>10:16</time>
<what>other error<what>
</log>
<log>
<time>10:29</time>
<what>segmentation fault</what>
</log>
</logfile>
-------------------------------------
ptree data; ptree::path p;
read_xml("logFile.txt",data);
string swhat = data.get( p / "log" %1 / "what" ):
-------------------------------------
What do you think?
> I'm thinking how to merge it with another important suggestion, which is to
> allow paths of arbitrary type, not only strings (for example arrays of ints,
> where each int is an index on its level, in some cases this might be
> useful). Having the path class, whole path parsing should be done by path
> objects. Probably the best approach would be to templatize basic_ptree on
> path_type and require certain functionality from it.
I like more the path to be ortogonal to the tree, i think we may need to use
differents paths in the same ptree, like a simple path in some point and
a reverse_path in other place, or even maybe a relative_ path.
Something like:
ptree data;
for( Humans::iterator h = humans.begin(), end = humans.end(); h != end; h++ )
{
ptree::relative_path p(data, h->name + ".info" );
data.put( p / "age" , h->age );
data.put( p / "nick" , h->nick );
data.put( p / "dir" , h->dir );
}
But maybe is too flexible... and you can impose to only use one kind of path.