Boost logo

Boost :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-04-23 09:38:28

David Abrahams wrote:

>> Hmm... then shouldn't it be guaranteed somehow?
> Well, I may have been wrong. The forward iterator requirements say:
> expression operational semantics assertion
> ---------- --------------------- ---------
> ++r r == s and r is dereferenceable
> implies ++r == ++s .
> X u(a); X u; u = a; post: u == a .

Oh, yea. Together with requirement that "r == s" implies "*r == *s" it seems
to guarantee that ++ does not invalidate copies.

BTW, do new iterator requirement state that iterator type X is interoperable
with itself? If so, then both old and new requirements are equivivalent
w.r.t. invalidation of copies.

>>>> 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.
>>> Yes, and it mean that not all readable single-pass iterators are input
>>> iterators, so I'm against it.
>> What input iterators requirements will be violated?
> Sorry, I got it backwards. Not all input iterators will be readable
> single-pass iterators. Either way, it creates a problem I think.

Right, I think directory_iterator will be affected, in particular.
>>>>>> 3) require that result of r++ is dereferencable and is equivivalent
>>>>>> to the dereferencing of the previous value of 'r'.
>>> Well, that requirement is equivalent to input iterator's requirement
>>> on "*r++".
>> In fact (3) is a bit stronger:
>> iterator copy = it++;
>> value_type v = *copy;
>> is required to work by it, while standard input iterators are required to
>> support *r++ as a single lexical expression.
> In that case, I don't want to ask for what you intend by 3, because
> it means not all input iterators will be readable single-pass
> iterators.

Ok, agreed.

>>> The question is, in which concept does that requirement
>>> go? It's neither a pure access nor a pure traversal concept.
>> And this requirements does not make sense for writable iterators... maybe
>> it can be documented in single_pass iterator, like:
>> if iterator is also a model of the readable iterator concept, then
>> expression *rv, where rv is the return value should be equal to
> ^^^^^^^^^^^^
> of what?

Of the "*rv" expression.

>> the previous value of iterator.
> I don't understand it, but I think something along those lines will be
> needed. We can probably use the "pre:" construct as shown in

Yea, that's possible.

>> The requirements for forward_iterator can specify that operator++ does
>> not invalidate any copies of the iterator and does not change the value
>> returned from operator*() of copies.
> Huh? I can't change the forward iterator requirements.

Ah, I mean "forward traversal iterator" and anyway this is already

>> That's great.
> Well, but we weren't on the same page about the meaning of 3.

Hopefully we're on the same page now.

>> Does it mean I can go and enable proxy in directory_iterator?
> Well sure, I think that was always legal.

Okay, I'm going ahead.

>> Or, maybe, it's better be addressed in the iterator_facade?
> Yes, IMO, but I am wondering how it should be done?
>> Say, so that proxy is always used for readable single-pass
>> iterators? I guess if iterator stores a value inside, it can always
>> to lvalue iterator, so always using proxy for readable iterators
>> seems OK.
> Maybe it'd be best to use a proxy only for non-lvalue iterators?

Isn't non-lvalue the same as readable? Or iterator_facace can be used for
making writable iterators? I think it can be used, but it that I'm not sure
what operator++(int) should return...

> Thanks for your attention to this; it makes a big difference!

You're welcome. In fact, I only now understood how complex iterators are --
due to this discussion and a couple of other iterator-releated issued I had
today. It's really good there are formal requirements.

- Volodya

Boost list run by bdawes at, gregod at, cpdaniel at, john at