"Joao Abecasis" <jpabecasis@zmail.pt> wrote in message news:421E32DE.9020203@zmail.pt... Thorsten Ottosen wrote:
"Joao Abecasis" <jpabecasis@zmail.pt> wrote in message news:421E01EA.6020105@zmail.pt...
| From the basic iterators other types of traversal are possible. In my |unfinished tree library (see my other post) the same effect would be |accomplished with: | | inorder_iterator<tree_t::tree_iterator> i = tr.root(); | preorder_iterator<tree_t::tree_iterator> i2 = tr.root(); | | This keeps the interface and the implementation of the tree cleaner. One | could also use BGL algorithms here if the tree exposes a Graph interface.
you can still have your clean separation, but I would prefer to expose it as typedefs in the tree. That is going to be much more pleasent in generic code. | |Ok. This seems to be a matter of taste, but I have to ask... Why is a |typedef more pleasant in generic code then a separate template? |
well, if the tree is a dependent name, we will have to write inorder_iterator< typename tree_t::tree_iterator > i = tr.root(); instead of typename tree_t::inorder_iterator i = tr.root(); I guess this would be even better: inorder_iterator<tree_t> i = tr.root(); (So I like that the most) |You could have a single algorithm that takes different linearization |schemes like preorder and postorder as a template parameter and needn't | care what their names are. or you could have two different algorithms sharing a common implementation if that is possible. But given the choice between writing boost::algo<boost::inorder_tag>( the_tree ); boost::algo_inorder( the_tree ); I prefer the last; it will be more pleasant to look at and produce better error messages. -Thorsten