2006-04-18 10:57:51 UTC
Helllo, and thangs again for your nice comments and suggestions. There would certainly be advantages to having the tree's modeled more in more of a 'key' fashion, but I decided against that when designing the tree, as it would make the tree more complicated to use. There are, however, a couple of ways the node order can be customized by the user. One, is by defining the < operator for the stored_type. Another method is to provide a second 'node_compare_type' template parameter. This would be similar to providing a comparison type to std::set, which determines the order of the objects in the set.
It's true that the entire node object might not be known to perform a search for one of the nodes. However, just as when searching for an object in the std::set, only the object members which determine the order of the set need be populated in the object to perform a search. So, if you provide a constructor to your stored_type which accepts only the parameter(s) necessary to set the 'key' members of the object, searching for a node is as easy as...
my_tree.find(CEmployee(2354));
Again, your suggestion about using a map for internal storage and modeling the trees as 'keyed' type containers is very understandable, and something I gave a lot of consideration to while developing the TCL. In the end, simplicity and ease of use were the deciding factor.
