Boost logo

Boost :

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-10-17 11:25:47

>From: "Samuel Krempp" <krempp_at_[hidden]>

>le Dimanche 13 Octobre 2002 18:59, tslettebo_at_[hidden] écrivit :

>> As pointed out in another posting, as I understand, the only thing you
>> safely do with an end() iterator is to compare it with other iterators.
>> Without this guarantee, it would limit how you could implement the end()
>> iterator. See my other posting with the tree-iterators for an example.
>> would you implement operator--() on that end() iterator?

>Well, schematically, the tree iterator I wrote keep a pointer to the root
>of the tree from which it came, plus a 'current node' pointer that is set
>to NULL for end().
>then calling -- on an end pointer does :
>.go to root
>.{go down, and to your right, as much as you can }

>it's very similar to what you do in ++begin() for an In-order iteration.
>And even in post-order, when at a node on the bottom, calling ++ might
>lead to more internal node iterations than --end()
>(as you need to first go up. possibly up to root).

>All in all I don't see tree iterators as an argument to disallow --end().

No, that wasn't the point, either. The point was that the implementation I
mentioned wouldn't be able to handle --end(), yet it would be able to use
end(). However, I've since read up on the iterator requirements, and found
that such an iterator would not be a conforming bidirectional/random access
iterator, either (as mentioned earlier in the thread).



Boost list run by bdawes at, gregod at, cpdaniel at, john at