Jose wrote:
* 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
Also for setting configuration data and simlpe xml-files? Mind you, many people would like a generic tree in boost, but few has said property_tree should be one too. And the interface of that tree is rather large (which of course is handy whn you need that). The fact that keys are duplicated in a map to provide fast lookup kinda rules out it to be a generic tree container where overhead is not acceptable.
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.
E.g.
* How easy is to use this existing file format with ":" separator
name1: value1 name2: value2
* How easy is to use a more advanced format, e.g. a CSS file
h1 { font-family: arial; font-size: 12px; } ..show { ... }
This also should be explained in the docs.
Not only should it be explained in the docs, but it should be decided if this is what the library is intended to do. And if yes, how would that framework look like? -Thorsten