From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2005-02-23 09:24:24
"Justin Gottschlich" <jgottschlich_at_[hidden]> wrote in message
| "Thorsten Ottosen" <nesotto_at_[hidden]> wrote in message
First, I agree with Richard's comments about structure and structure
manipulatig operations--this is the important part.
| > One major issue with the design: I don't like that iterators are trees. It
| > must be possible to break the two concepts apart like in
| Thorsten, you're absolutely right - that's really the big "question", the
| one I've struggled with for months really. I could definitely design the
| tree so iterators are not trees, but I'm not sure that's correct.
| 2) This example shows the how inserts are done into subtrees from iterators:
| core::tree<char> t;
| *t = 'a';
see, this seems just wierd that *t = ... is defined for a tree. I could accept
fact that you iterate over subtrees, but the design would have to be like this
template< class T >
then it would be natural that operator->() (not operator.()) of an iterator
returns a tree*. So
would seem natural.
You might want to find out if that node-structure is not the best way to
implement the tree. The design above does not require any node concept.
| > For all iterators I would like to be able to say
| > if( i.is_leaf() ).
| That's a great suggestion too - I don't have that as a direct function call,
| but can achieve it by this:
| if (0 == i.size()) // it's a leaf if its size is 0, since it's checking
| the number of the elements it contains
yes, it should be fairly easy. I fell in my own trap an implemented is_leaf()
as a member function of the iterator. It could make sense to
have an is_leaf() member function as part of a tree-iterator concept, but
it should actually be a member function is a tree, so
would be to prefer IMO.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk