Boost logo

Boost :

From: Marcin Kalicinski (kalita_at_[hidden])
Date: 2006-04-28 08:38:35


Hi Jose,

Thank you very much for your review.

> I think the library should be named after what it does (not how it does
> it).
> The property tree is
> the container but in this case the library is about program
> configuration -
> Boost.ProgramConfiguration
> (there are other libraries where a more technical name is better because
> of
> the library scope, like the
> property map library, but not for this one)

The scope of the library is beyond program configuration. It can also be
used to manipulate DOM-like structures (which are trees), pass data inside
program etc. ProgramConfiguration would be misleading, it would suggest the
library is a superset of Program Options, which it isn't.

> 2. Relation to other libraries
> I think the relation to the Boost.ProgramOptions library is not clear.
> Maybe it should !

I will add into the docs (in prominent place) the goals/problem domain
statement I posted several days ago. I will also expand it with
PO/serialization/multi-index relationships.

> The use of the Spirit library for the xml parser is good. Using other
> boost
> libraries like serialization, .. do not seem correct for this specific
> library.

Correct. Serialization cannot be used for saving ptree file formats. In
general it is not meant to save arbitrary configuration files, even with
provision of custom archives. The format it follows it quite rigid, and
cannot easily be changed.

> * The weak points:
>
> a) The container
>
> The use of a generic tree container has not been seriously considered. The
> argument against using a generic container is that it would complicate
> the
> library.
> I don't agree. For a specific example check the tree.hh library: an
> STL-like
> C++ tree class
> http://www.aei.mpg.de/~peekas/tree/ This library provides a generic tree
> container
> and well thought-out interfaces. It is as easy or easier to use than the
> PT
> lib

tree.hh is GNU GPL licensed. Cannot use it in boost. Also, because it is a
generic tree container, its interfaces are inevitably generic as well. It
has very different strucuture from ptree, for example it does not have keys,
so you cannot use paths. It does not provide any type-conversion mechanisms.
It would require a large facade to be used in a role of property tree.

> b) The parsers (library vs utilities)
>
> It is not clear whether the parsers are utilities or whether the PT lib is
> supposed
> to provide some framework to build specific parsers.

The basic_ptree class is "the framework". I cannot think about any other
thing that different formats might have in common, so that it can be
factored out into some utility. For a very simple format, writing a parser
in spirit to populate ptree is not much more that 1 screen of code, most of
which is boilerplate anyway.

> Maybe one way out of this conundrum is to consider the current library
> as the basic one and later have an advanced version that really provides
> the generic container and the proper query mechanisms.

The problem is that this may never happen. Also, when it happens it might
turn out that the resulting library (being powerful and
standards-compliant), will be cumbersome to use in simple cases.

Best regards,
Marcin


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk