From: Roland Richter (roland_at_[hidden])
Date: 2004-04-14 12:23:37
> Here is an update to cycle_iterator. This is based on the original design
> by Gennadiy Rozental. After fairly extensive performance testing I am
> getting good results (compared to my old implementation which was
> hand-written, not based on boost iterators), after adding operator.
one important issue I came across:
Say I have a collection, and I want to iterate over all its elements.
For some reason, I don't want to do it from first to last, but I want
to start at the 7th element, iterate to the end, jump back to the
beginning, continue, and finish at the 6th element. Sounds like a
case for cycle_iterator, right? Here we go:
// Begins at 7th element:
cycle_facade<...> b = make_cycle_facade(v.begin()+7, v.begin(), v.end());
// Ends one past the 6th element:
cycle_facade<...> e = make_cycle_facade(v.begin()+7, v.begin(), v.end());
I guess you already see the problem: the loop
for( cycle_facade<...> it = b; it != e; ++it )
// do something
is exited immediately, since b and e here are considered _equal_ (which
is not what we intended).
My solution back then was to keep an internal counter which counts how
often the iterator got "past the end". In the case above, b would have
a counter of 0, whereas e got past the end once, i.e. the counter is 1.
Hence, b and e are no longer equal.
You might want to check out cyclic_iterator in boost/view from the
CVS Sandbox (and yes, it also uses the new iterator_adaptors).
I am aware that this might not be relevant in your case; yet, I'd like
to hear your opinion on this "equality" problem.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk