Vladimir Prus <ghost@cs.msu.su> writes:
David Abrahams wrote:
Vladimir Prus <ghost@cs.msu.su> writes:
And it seems to me, all single pass iterators have to store the value to allow for repeated operator*() calls.
Let's talk about concepts in the standard, i.e. input iterator.
Talking about input iterator, directory_iterator does not comply with *r++ requirement.
Yes, I know.
We invented single pass iterator; it can mean anything we say, and what we said doesn't imply that.
But it's the intention that new-style readable single-pass iterator is also a model of old-style input iterator?
Yes.
And the problem we're discussing is that directory_iterator is readable single-pass iterator but not input iterator?
Yes.
I see that std::input_iterator requirements say that after ++r any copies of the previous value of r are no longer required to be dereferencable.
Right. That rules out your scenario of keeping old copies of the iterator around and derferencing them later.
New iterators requirents are silent on this. Is this intentional?
Probably not. However, if the standard doesn't explicitly guarantee iterator stability, you can't count on it. That said, a note would probably be good to add.
If single pass iterator requirements ^^... - would add the same note about ++r making iterators dereferencable "non-"----------^ Probably a good idea.
- retain the same requirements for operator++(int)
Really you mean requirements on the expression "*r++", I think. ...then what?
The result of r++ is not required even to be dereferencable
Not required by which concept?
and *r++ is not required even to be to work for single-pass iterator, while it works for input iterators.
Right, that needs to be fixed.
The solutions I see are:
1) require that ++r does not makes any copies dereferencable, or
I think you mean "not require that any copies are dereferencable after "++r"?
2) allow returning proxy from operator++(int)
That doesn't allow all readable single-pass iterators to be input iterators. I'm against it. What would the proxy do, anyway?
3) require that result of r++ is dereferencable and is equivivalent to the dereferencing of the previous value of 'r'.
I think we need want 1&3.
The variant 2) would be most convenient for directory_iterator...
Yeah, but it would break interoperability with old algorithms. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com