Boost logo

Boost :

From: Matt Doyle (mdoyle_at_[hidden])
Date: 2006-04-19 13:52:20

> [mailto:boost-bounces_at_[hidden]]On Behalf Of Thorsten Ottosen
> I have the great pleasure to announce that the formal boost-review of
> Marcin Kalicinski Property Tree Library begins now (the 18th
> * What is your evaluation of the design?
> * What is your evaluation of the implementation?
I think that both the design and the implementation are sound, clearly a great deal of thought and effort went into this design. I like the container-like interface so that I can iterate through the tree but more so I like the ability to just enter the full path to the element that I want with out first having to search for it.

> * What is your evaluation of the documentation?
I think it could use some expanding upon. First, as was already mentioned, the index needs to be broken up into smaller topics. Next I think there should be more discussion (tutorial) on customizing the library.

> * What is your evaluation of the potential usefulness
> of the library?
Great! My opinion is that this library is going to see far more usage than just what it was intended for. My initial reaction when I looked at it is that it's more of a generic hierarchical tree, moreover, once you've populated your tree you can save it off and come back to it another day. Just taking those two aspects into consideration opens the door to a lot of possibilities, far more than just reading configuration data.

> * Did you try to use the library? With what compiler?
> Did you have any problems?
In process

> * How much effort did you put into your evaluation?
> A glance? A quick reading? In-depth study?
So far only a few hours, but more to follow.

> * Are you knowledgeable about the problem domain?
To a degree, yes.

> 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.
Absolutely! I think this library will be suitable for a number of applications.

> In particular, consider if you can answer the following questions:
> - was the library suitable for your daily xml-tasks? If not, what was
> missing?
> - was the library's performance good enough? If not, can you suggest
> improvements?
Performance is a concern given the recursive nature of the tree. I want write a test case parsing Usenet's group list. By it's nature it demands storage in a hierarchical tree where every node is both a leaf and a branch (like ptree :) , it's a big list, and insertion / retrieval is mostly random. Hopefully I'll have time to do this before the review is over.

> - was the library's design flexible enough? If not, how would you
> suggest it should be redesigned to broaden its scope of use?
The number one place I see this library being specialized, both by the users and the maintainer, is in the parsers. Case in point, my above test requires me to write a different parser. I think it would be useful in the long run to have a basic_parser<...> that could be inherited from as an interface to the user who needs to write their own parser. All the preprocessor stuff, or other implementation details, can be hidden there so that the user just inherits and parses away. There may be other places where customization hooks make sense... Any thoughts?

Matt Doyle

> best regards
> Thorsten Ottosen, Review Manager
> _______________________________________________
> Unsubscribe & other changes:

Scanned by McAfee GroupShield {X3BTB534}

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