Re: [boost] [Boost Review] Property Tree Library

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.