[Bug libstdc++/46906] istreambuf_iterator is late?

["daniel.kruegler at googlemail dot com" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46906

--- Comment #10 from Daniel KrÃgler <daniel.kruegler at googlemail dot com> 2011-09-05 14:17:14 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > Why do you think that either implementation form could be
> > considered as non-conforming?
> 
> When I read that operator* returns sgetc(), I understand that as 
> assert(*i==buf.sgetc()).

But as explained below this requires that no further external source modifies
the stream (buffer) at the same time. It is unspecified whether an
implementation caches the read value or not. Both implementations seem to be
conforming, because an input iterator is not required to return an identity
from operator*.

> If there really is a provision that lets *i return what buf.sgetc() used to
> return (I am not convinced the (void)*a,*a thing is it), it would be nice to
> remind it in the definition of operator*.

The "(void)*a, *a" requirements ensures that you can invoke operator* several
times without a value change of the result. This holds for both implementations
if no external changes happen to the stream buffer. I agree that the wording
does not say this very clear.

> And I guess I don't really like this
> kind of unspecified behavior... (it is very different from copy elision for
> instance)
> 
> But it wouldn't be the first time that it is my understanding of the standard
> that is at fault ;-)

You could request an LWG issue for this to clarify the intent or to enforce
only a single valid implementation, provided there are some good reasons for
this.