Hi Andy, First of all, sorry I did not reply sooner. The interest in the library is quite large and there is only that many posts I can answer per second ;-) Additionally, I spent most of today on ACCU conference, and so have developed a huge backlog.
AFAICS the current ptree could be a refinement of a a generic tree container, however the current design of ptree is not so defined and its probably not going to be possible to 'reverse engineer' genericity from the current design.
I think generic tree is a material for another library. The question if property_tree should be based on one is just an implementation issue, not of much interest to users. The biggest virtue of property_tree is easy to use interface. If we try to make generic tree of it, it will be compromised. This should not happen, because people will then prefer to use Expat or MSXML instead.
[...] ptree doesnt distinguish the concepts of a branch and a leaf. It is possible to imagine an alternative design in which a branch can be iterated over whereas a leaf cannot, and the 'data' in a branch is a container of nodes whereas the data in a leaf is not.
I never before thought of using polymorphism to distinguish between branch and leaf nodes. The reason is I never saw need to. For example this would imply that as soon as you add children to leaf it changes type (i.e. must be destroyed and reconstructed - what happens to pointers/references somebody may be holding?). My feeling is that interface would get quite muddled if I adopted that sort of approach.
But it would be interesting to know why you have chosen this design over others. That is not stated in the docs AFAICS. It would help when I wanted to use such a library because it could help me to make a fast decisison as to whether it was suitable.
Main reason was existing practice. I used this type of container for many years before I even considered writing any docs, let alone submitting it to boost. I had quite a lot of experience where and how it could be used. Plus the implementation I had - refined over several years - was starting to look mature. I knew it had general value, because it helped me on many projects. And the short answer is I never considered completely different implementation because the one I had worked, and I had other things to worry about :-)
BTW the current 'Rationale' section looks more like a 'FAQ' section FWIW.
That's right. I think it was bigger in the past, but many explanations proved to be ill thought out, and I had to remove them ;-) If this continues I might be forced to remove this section completely.
Library would need some sort of path parsing policy [...]
One option I envisage is to make a symbol table, where each new string token encountered is given an integer id, and only the id's are stored in the tree. The intent being to speed up key lookups. In this case a path to a node consists of a linear container (e.g a vector) of integer ids.
I think this could be done if I implement key policies. You just define key type to be a vector and supply appropriate head/tail functions (which would be trivial in this case). Thank you, Marcin