Marcin, comments below. Marcin Kalicinski wrote:
Dear Everybody,
It was a real pleasure to read this post. I am sure there are many people who feel the library needs polishing and rethinking in some areas. A lot of interesting ideas were proposed during the review, and I already started work on the next revision. I hope the changes I intend to do will make these people less concerned about the quality and usefulness of the library, while they will not detract from what other people found valuable. Below is a (possibly incomplete) list of improvements I intend to add in future revisions:
- path class, orthogonal to the tree - configurable location of metadata generated by the parsers (e.g. XML attrributes information). It may be possible to achieve that for free with paths - generation of comments / layout metadata by parsers - splitting traits - support for using custom types for keys, again path class looks like a solution - documentation rewrite to QuickBook, and enhancements (thanks to Charles Brockman who provided tons of English-related corrections)
I unfortunately did not have the time to review your library, even though I knew I would try to use it in my configuration file handling stuff. Hope you don't mind if I add a couple of wishes/suggestions based on my recent usage: - It should be possible pass the path separator char to the ctor, which then should be used as the default for all operations. This wish might be partly invalidated if/when you implement a path class. I still haven't stumbled upon a use case where different path separators need to be used within the same property tree. - Preserve the possibility (in path class or wherever) to use a plain text string to specifiy a path. Please. - Add a 'name()/full_name()' method to the interface; the name() method would return the current tree 'leaf' name and the full_name() returns the complete path from the root. - Add 'parent()' method. - Add support for relative paths; e.g. ptree::get("../sibling/arg") - I'm personally not found of e.g. operator[] acting the way as the std::map subscription operator. If you implement operator overloading for the path handling, please support failures being reported if the path elements does not exist (via supplied error handling policy or similar). Thanks for an already very usable library. Regards / Johan