[PATCH] Cleanup in istream.tcc

[Martin Sebor]

Pétur Runólfsson wrote:

...
> I see that there is now a defect report about this (419).
> I mostly agree with the proposed resolution, except for this:
> 
> 
>>I think I like the first alternative better (i.e., there's no reason
>>to call setstate(failbit) if the bit is already known to be set).
> 
> 
> It seems more consistent to always set failbit if !good(). If
> both failbit and badbit are set in exceptions,
> 
> is >> x;
> 
> will either succeed or throw an exception, and x can be used after
> the call without first checking is.fail().

That makes sense to me, but what about badbit? Btw., you might want
to consider joining the committee (e.g., as an observer) and providing
your comments on the issues you're knowledgeable about to the whole
group.

> 
> 
>>In particular, readsome() is explicitly required to set failbit when
>>the sentry is false.
> 
> 
> This is an even better reason that the resolution of 419 should
> be to always setstate(failbit) if !good(), otherwise the behaviour
> of readsome() will differ from the other input functions.

I have a feeling that the behavior of some functions might change
one way or the other either way, because the error handling policy
in iostreams is less than 100% consistent(*). But I might be wrong.

Martin

(*) Hence my RFC on the issue: "I haven't done a full survey of all
the input functions to make sure the change doesn't break something
else. A second pair eyes would be helpful."