Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates
 64.233.170.190 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:organization:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:sender;
        b=dvGHGZ9dPjjrcf8nLGA8aLZWcmjkLmVXmc9G7S0Anir+N9E64HjCjZWP9KB1jBB1AyfvOzZ5pvV4ewXNgqC7QuMTVrJQLHNhQGhdYE9sX15a0040nq8El1VCduBFBCBQVoKsrP1Raog9mpvjc+zzhiw9+xNmJmjju0CTV1Qiqb4=
Message-ID: <4731DEB1.8070901@roguewave.com>
Date: Wed, 07 Nov 2007 08:50:09 -0700
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 1.5.0.12 (X11/20071019)
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: another istream_iterator question
References: <472CB093.5060105@gmail.com>
In-Reply-To: <472CB093.5060105@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: Martin Sebor <msebor@gmail.com>

Mark Brown wrote:
> I have been looking at the istream_iterator class, mostly out of
> curiosity than to try to fix a specific bug, to see if there are
> any other discrepancies with the standard and operator++ caught
> my attention. The standard says that the operator should return
> *in_stream >> value but the stdcxx definition looks like this:
> 
>     istream_iterator& operator++ () {
>         return _C_strm && !!*_C_strm && (*_C_strm >> _C_val), *this;
>     }
> 
> There are two extra checks that aren't required by the standard.
> They are probably harmless but I wonder if they shouldn't be
> removed for efficiency. Does anyone see a problem with such
> a change?

I see no problem with it. We should assert that _C_strm is non-null
before dereferencing it but other than that I see no reason to try
to prevent undefined behavior (the effects of operator++ are
undefined once the iterator has reached the end of the sequence).

Martin

> 
> --Mark
>