From: Sebastian Redl (sebastian.redl_at_[hidden])
Date: 2006-04-19 11:26:35
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk