From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28406 invoked by alias); 5 Sep 2011 14:17:40 -0000 Received: (qmail 28390 invoked by uid 22791); 5 Sep 2011 14:17:38 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 05 Sep 2011 14:17:21 +0000 From: "daniel.kruegler at googlemail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/46906] istreambuf_iterator is late? Date: Mon, 05 Sep 2011 14:17:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: daniel.kruegler at googlemail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2011-09/txt/msg00325.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D46906 --- Comment #10 from Daniel Kr=C3=BCgler 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? >=20 > When I read that operator* returns sgetc(), I understand that as=20 > assert(*i=3D=3Dbuf.sgetc()). But as explained below this requires that no further external source modifi= es 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* sever= al times without a value change of the result. This holds for both implementat= ions 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 f= or > instance) >=20 > But it wouldn't be the first time that it is my understanding of the stan= dard > 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.