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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-04-23 00:51:34

David Abrahams wrote:

>> 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.

True. I did not see that clause until yesterday.

>> 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.

Okay. BTW, what guarantees that ++r does not invalidate any copies for
forward/bidirectional/random iterator? 

>> 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.

No, on operator++(int)

>     ...then what?
> 
>> The result of r++ is not required even to be dereferencable
> 
> Not required by which concept?

By nothing I could find in new iterator requirements. Requirements on
operator++(int) say:

   {
       X tmp = r;
       ++r;
       return tmp;
   }

operator++ is allowed to invalidate 'tmp', and nothing explicitly requires
return value from operator++(int) to be dereferencable.

>> 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"?

Nope, I meant what written. If ++r is required to keep the copies
deferencable then *r++ will be guaranteed to work. OTOH, this would require
storing value in iterator which as you say is not indented by current
input_iterator.

>> 2) allow returning proxy from operator++(int)
> 
> That doesn't allow all readable single-pass iterators to be input
> iterators.  I'm against it.

It's possible to require that return value from operator++(int) is some type
with operator* and application of operator* returns the same value as the
*it before incrementing.

> What would the proxy do, anyway?

Here's commented out code in filesystem lib:

      struct path_proxy // allows *r++ to work, as required by 24.1.1
      {
        path pv;
        explicit path_proxy( const path & p ) : pv(p) {}
        path operator*() const { return pv; }
      };

      path_proxy operator++(int)
      {
        path_proxy pp( m_deref() );
        ++*this;
        return pp;
      }

>> 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.

Will 3) require extra storage in iterator? Now, transform_iterator can store
only wrapped iterator and a functor. If 3) is required it should
additionally store either value, or a flag telling there's a undereferenced
copy (as you've suggested). Besides, In the second case it should be stated
that return of r++ is dereferencable untill you call operator*() or
operator++() on original iterator.

> > The variant 2) would be most convenient for directory_iterator...

> Yeah, but it would break interoperability with old algorithms.

Why? Input iterator requirements only say that *r++ should return T. They
don't say anything about type of r++.

- Volodya

Yeah, but it would break interoperability with old algorithms.