This concept is a refinement of Input Iterator, adding the requirements that the iterator can be used to make multiple passes through a range, and that if it1 == it2 and it1 is dereferenceable then ++it1 == ++it2. The Multi-Pass Input Iterator is very similar to the Forward Iterator. The only difference is that a Forward Iterator requires the reference type to be value_type&, whereas MultiPassInputIterator is like Input Iterator in that the reference type merely has to be convertible to value_type.
comments by Valentin Bonnard:
I think that introducing Multi-Pass Input Iterator isn't the right solution. Do you also want to define Multi-Pass Bidirectionnal Iterator and Multi-Pass Random Access Iterator ? I don't, definitely. It only confuses the issue. The problem lies into the existing hierarchy of iterators, which mixes movabillity, modifiability and lvalue-ness, and these are clearly independent.
The terms Forward, Bidirectional and Random Access are about movabillity and shouldn't be used to mean anything else. In a completely orthogonal way, iterators can be immutable, mutable, or neither. lvalue-ness of iterators is also orthogonal with immutability. With these clean concepts, your Multi-Pass Input Iterator is just called a Forward Iterator.
Other translations are: std::Forward Iterator -> ForwardIterator & Lvalue Iterator std::Bidirectionnal Iterator -> Bidirectionnal Iterator & Lvalue Iterator std::Random Access Iterator -> Random Access Iterator & Lvalue Iterator
Note: In practice the only operation not allowed on my Forward Iterator which is allowed on std::Forward Iterator is &*it. I think that &* is rarely needed in generic code.
reply by Jeremy Siek:
The above analysis by Valentin is right on. Of course, there is the
problem with backward compatibility. The current STL implementations are
based on the old definition of Forward Iterator. The right course of action
is to get Forward Iterator, etc. changed in the C++ standard. Once that is
done we can drop Multi-Pass Input Iterator.
Copyright © 2000 Jeremy Siek, Univ.of
Notre Dame ([email protected]) |
|