Boost logo

Boost :

From: Sebastian Redl (sebastian.redl_at_[hidden])
Date: 2006-04-19 06:38:06

Here's my preliminary review of the property tree library.

> * Are you knowledgeable about the problem domain?
I'm a student of software engineering and have repeatedly written
programs that require external configuration, mostly in C++, Java and PHP.

> * How much effort did you put into your evaluation?
> A glance? A quick reading? In-depth study?
I've begun using the library as the main means of configuration in a
project. I have not yet, however, compiled any code or looked at the
library source code.

> * What is your evaluation of the design?
The design is straightforward and sound. The compatibility with standard
containers makes the learning curve shallow, and the specialized
functions offer an easy interface.

> * What is your evaluation of the implementation?
I did not look at the implementation.

> * What is your evaluation of the documentation?
The documentation is generally good. However, it could be better
structured - in particular, the documentation index page is too long and
needs to be split into parts. The documentation also requires attention
from a native English speaker to correct the various grammar errors.

> * What is your evaluation of the potential usefulness
> of the library?
High. It offers a flexible and universal interface to many different
forms of configuration sources in a way that I have yet to see in any
other language/library.

> * Did you try to use the library? With what compiler?
> Did you have any problems?
I've so far written a bit of source code using the library, but have not
yet compiled the code. It will eventually be compiled using GCC 3.4.x
and 4.x.

>And finally, every review should answer this question:
> * Do you think the library should be accepted as a Boost library?
> Be sure to say this explicitly so that your other comments
> don't obscure your overall opinion.
Yes. Already it transforms a job I've been dreading to do (and so far
have reinvented every time, because I was never satisfied with my
approach) into a matter of 5 lines. (Literally!) Enhancements from here
on are incremental and their lack does not matter right now.

>In particular, consider if you can answer the following questions:
>- was the library suitable for your daily xml-tasks? If not, what was
The library seems very well suited to read and save XML configuration
files. I would suggest, however, that versions of read/write_xml are
introduced that allow to specify the special keys for attributes,
comments and text. Also, a flag should be added that specifies
whitespace handling. (Ignore, preserve, collapse.)

>- was the library's performance good enough? If not, can you suggest
No performance testing done.

>- was the library's design flexible enough? If not, how would you
>suggest it should be redesigned to broaden its scope of use?
Seems flexible enough for me, thanks to the key and value type traits.

Additional suggestions:
1) Having a separate namespace for the interface of each parser seems to
be overly verbose. The property_tree namespace is sparsely populated
(just ptree, a few predefined traits classes, and the exceptions if I'm
not mistaken), so the read_* and write_* functions could reside there.
Alternatively, a single namespace parsers could be created to hold all
interface functions. Assuming pt is an alias for the property tree
namespace, pt::xml_parser::read_xml contains redundant information about
the type being read.
2) Add a parser for Java-like .properties files. The hierarchy could be
built using common prefixes, i.e.
build.dirs.libraries = /usr/lib
build.dirs.headers = /usr/include
could be transformed to
build {
  dirs {
    libraries = /usr/lib
    headers = /usr/lib
3) The default separator should be settable. E.g. if I want to always
separate my paths with '/' (I could be porting from a different
library), I want to be able to write:
string libs = pt.get("build/dirs/libraries");

Perhaps I'll have additional comments at a later point.

Sebastian Redl

Boost list run by bdawes at, gregod at, cpdaniel at, john at