"Joaquín Mª López Muñoz" <joaquin@tid.es> wrote in message news:421DD6FC.A717DC5@tid.es... Thorsten Ottosen ha escrito:
"Justin Gottschlich" <jgottschlich@runbox.com> wrote in message
I'm not sure I like the expression "trees as algorithms". I would like to see different types of iterators which can then be used to implement algorithms.
So I only see trees as containers.
|I agree with Thorste here. Thinking about the relation between a tree |structure and its various iterators, maybe we can adopt a similar conceptual |approach as Boost.MultiIndex: a tree container is the underyling data structure, |on top of which several "indices" are provided with different iteration policies: | |typedef tree<element> tree_t; |tree_t tr; | |tree_t::iterator<inorder>::type it1=tr.get<inorder>().begin; // inorder iteration |tree_t::iterator<preorder>::type it2=tr.get<preorder>().begin; // preorder |iteration | |// convertibility between different types of iterators |it2=tr.project<preorder>(it1); I'm not to keen on the idea that iterators are parameterized with an iteration policy. It would be more natural just to have tree_t::inorder_iterator i = tr.inorder_begin(); tree_t::preorder_iterator i2 = tr.preorder_begin(); This shouldn't prohibit conversion between the iterators AFAICT, but it will remove the need for a lot of template stuff which is only there to make the stuff harder to use and to make error messages harder to read. br -Thorsten