Andy Little wrote:
Why are all ptree nodes the same type? Commonly a tree will have branch and leaf nodes. In the debug example there are two branch nodes and 4 leaf nodes, which means two empty lists . That is wasteful isnt it?
How do you distinguish, though? What happens when you add a node as a child of what formerly was a leaf node? How can you change the type of the node when some places (including, most likely, the caller) are holding a reference? How would you define value_type? Would you make the tree node polymorphic? Isn't that even more wasteful? (Not to mention cumbersome.) An empty list is just two pointers, and perhaps a count.
Is it necessary to make key a string. Could it not also be (say) an integer id?
It's certainly possible in theory, and the key_type typedef in the traits should make it possible in practice too. From looking at the implementation, it appears, however, that the key type must provide the std::string interface. This makes sense, in a way, as the keys can be concatenated to directly access deep properties. The question is whether making this more flexible, either by having the traits supply a conversion from string to key and do the lookup by tokenizing and converting each token, or by having the traits supply a type-specific concatenation operation, is worth the trouble. Using any key type but string makes most of the readers and writers useless: the existence of any XML where all element and attribute names are numbers is doubtful (and perhaps even forbidden, I'd have to check the specs). In addition, such an interface makes the implementation and the traits that much more complicated. Sebastian Redl