This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [PATCH] Cleanup in istream.tcc
- From: Martin Sebor <sebor at roguewave dot com>
- To: Pétur Runólfsson <peturr02 at ru dot is>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Wed, 24 Sep 2003 11:18:34 -0600
- Subject: Re: [PATCH] Cleanup in istream.tcc
- References: <07D05A69A3D0C14FAEA60C3ACE8E5564028F55CD@mail.ru.is>
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."