For input iterators, why a == b does not imply ++a == ++b?

Question

§24.1.1/3 from C++03 Standard reads,

For input iterators, a == b does not imply ++a == ++b. (Equality does not guarantee the substitution property or referential transparency.) Algorithms on input iterators should never attempt to pass through the same iterator twice. They should be single pass algorithms. Value type T is not required to be an Assignable type (23.1). These algorithms can be used with istreams as the source of the input data through the istream_iterator class.

I couldn't understand the bold text in the above quotation. Can anyone help me understanding this?

Also, what does the following statement (italicized text in the above quotation) mean? How is it related to a==b and ++a==++b expressions?

Equality does not guarantee the substitution property or referential transparency.

Answer 1

For Input Iterators, incrementing an iterator invalidates copies of the same iterator.

So:

auto a = istream_iterator<whatever>(something);
auto b = a;
a == b; // true
++a;    // b is now invalid
++b;    // undefined behavior, I think, but in any case not guaranteed to
        // result in anything sensible.

So certainly ++a == ++b is not guaranteed. That is, a == b does not imply ++a == ++b.

I think the "substitution property" means "anything you do with the value of a has the same result as doing the same with the value of b", or similar - there are various versions of substitution that it might refer to, but something along those lines. I think in this context it must mean "later doing the same with b", since if a == b and I haven't done anything invalid yet, then it doesn't matter which of a and b I use, they refer to the same point in the stream. But when I increment, I do have to pick one and lose the other, hence the difficulty with ++a == ++b.

"Referential transparency" means that different objects are independent, i.e. they're not references/pointers to or aliases of each other. In combination with "substitution property" this means:

Later? There is no earlier or later since operations don't have global side-effects. If you can't substitute "later" then you can't substitute

Input iterators in the same sequence typically refer to the same "actual data", like a file handle or whatever, which itself contains mutable state. Since a and b refer to the same file handle, and their value is dependent on its state, you don't have referential transparency. This lack is why substitution fails.

Forward iterators typically also refer to the same underlying data (like a container), but as long as you use them read-only (and don't otherwise modify the container), they don't betray this fact, at least not until you start comparing the addresses of the values they return. So they have a limited kind of referential transparency of their own value, that input iterators don't. They're still references themselves, so the things they refer to are still aliased.