[boost] Re: [filesystem + iterator] directory iterator problem

From: David Abrahams (dave_at_[hidden])
Date: 2004-04-22 10:02:19

Vladimir Prus <ghost_at_[hidden]> writes:

> David Abrahams wrote:
>
>> Vladimir Prus <ghost_at_[hidden]> 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