[...] Hope you don't mind if I add a couple of wishes/suggestions based on my recent usage:
You're very welcome! Suggestions based on real-life experience are the most valuable. As you can see below I agree with most of your comments.
- 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.
One problem with it is that different nodes in the same hierarchy may end up with different separators. Another problem is that every node will store a copy of the separator, a waste of memory.
- Preserve the possibility (in path class or wherever) to use a plain text string to specifiy a path. Please.
Yes, definitely. No worries :-) Judging by people's comments this has been one of the biggest selling points of the library. Judging by my experience with ptree, string paths are very useful. While path classes may provide additional flexibility and performance where it is needed, string paths will continue to provide simplicity and ease of use in a majority of real life cases. How exactly this will be implemented is another issue.
- 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.
If done, this should return a path object which could optionally be turned into a string if needed. But it is dependent on having parent data member.
- Add 'parent()' method.
The reason why there is no parent() is that originally ptree held children by pointers, not by values. This allowed, among other things, storing a single child in many parents. Obviously, there was no good way to implement parent() then, so it wasn't there. I dropped the pointers long time ago and replaced them with values, because they were causing too much trouble and some of the advantages they provided could be simulated another way. Now that the tree only has one parent, parent() can be done easily. At the moment I don't see any reason it should not be done.
- Add support for relative paths; e.g. ptree::get("../sibling/arg")
Yes, if parent() is implemented, paths must support some sort of tree-walking.
- I'm personally not found of e.g. operator[] acting the way as the std::map subscription operator.
I've done an experiment with operator [] recently. John Maddock presented it quite nicely, proxy objects for nonexisting nodes, templated conversion operators, etc., so I didn't have to do much thinking. It is very clever and works, at least as far as I implemented it. But after the experiment, I think it is actually _too_ clever. In case of ptree, I believe operator [] based interface is inferior to named functions. The reason is readability. There are too many operations one can do on a node to cram them all into a single-parameter operator. From my experiment, it looked more like an exercise in C++ aerobatics, than a robust solution. Concluding, it has its virtues, and I don't shelve it yet, but I must try something else first. Regards, Marcin