|
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
can
>> 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.
How
>> 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).
Regards,
Terje
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk