[boost] Re: Boost library inclusion: generic tree containers?

From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-02-24 16:37:40

"Joao Abecasis" <jpabecasis_at_[hidden]> wrote in message 
news:421E32DE.9020203_at_zmail.pt...
Thorsten Ottosen wrote:
> "Joao Abecasis" <jpabecasis_at_[hidden]> wrote in message
> news:421E01EA.6020105_at_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