From: Darren Cook (darren_at_[hidden])
Date: 2006-04-21 22:23:54
> The documentation may be viewed online at
> - http://kaalus.atspace.com/ptree/doc/index.html
BTW, this URL has timed-out every time I've tried the past week. But the
docs were in the zip file in the boost vault.
> * What is your evaluation of the design?
I like that I can write get("myvalue",default) which will always return,
or get("myvalue") which will throw if not found.
The use of <xmlattr> to access attributes is ugly, but I don't have a
better suggestion (except shortening it slightly to "<attr>"). One
alternative would be a get_attr() family of functions but that they
would be XML-specific, so that is uglier.
> * What is your evaluation of the implementation?
> * What is your evaluation of the documentation?
Good enough. It needs a few minor fixes by a native English speaker.
I didn't see the need for get_own(), so that could do with a motivating
> * What is your evaluation of the potential usefulness
> of the library?
I think it fits the desired goal of reading in a configuration file.
Versus Program Options: I've not used this library, but when I skimmed
the library docs yesterday I didn't see examples of reading an XML
configuration file. Or JSON.
Versus Serialization: Hhhmmm...
Firstly I've seen people saying the serialization library is a
heavyweight solution. In terms of number of lines you need to write I've
not found this. It is as simple to use as Property Tree.
If I was reading/writing a config file and the editing of settings was
only done through my program, then I would definitely use the
The problem with the serialization library is that the XML format is not
easy to edit. I doubt it can be friendlier and still work, or Robert
Ramey would have done it that way?
There is a need to be able for a program to be able to write to its
setting file but also have the settings file be easy to view and edit.
The Property Tree library fills this need.
> * Did you try to use the library? With what compiler?
> * How much effort did you put into your evaluation?
Just reading the docs once, and following the discussion here.
> * Are you knowledgeable about the problem domain?
> * Do you think the library should be accepted as a Boost library?
Ideally I think it should be merged into the Boost Serialization library
as additional format options (i.e. in addition to the current binary,
text and xml formats, add easy-to-read-xml, json and ini files).
If, as I suspect, that is technical not feasible, then I vote Yes.
> - was the library suitable for your daily xml-tasks? If not, what was
Probably not. XML files containing lots of data (as opposed to a
relatively short, human-editable configuration file) usually use
namespaces, entities, CDATA, etc.
I usually use PHP for dealing with such files, and I'm satisfied with that.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk