Re: Stream states questions
On Sep 11, 5:44 am, Jerry Coffin <jcof...@taeus.com> wrote:
In article <1189418256.683256.201...@y42g2000hsy.googlegroups.com>,
james.ka...@gmail.com says...
[ ... ]
No I'm not. The exception mask is exactly identical with the
bits: if you ask for an exception on eofbit, you get one on
eofbit (which is totally useless).
While certainly the least often to be useful, I can't agree that even
that one is totally useless. An obvious example would be if the program
has previously written out a temporary file so the contents should be
precisely predictable. If it encounters eof while reading what it knows
should be available, that might well be a truly exceptional condition.
That's failbit, not eofbit. An exception will be raised by
eofbit even if the stream hits EOF when reading ahead, to
determine where to stop. Thus, for example, if the file
contains just "1234" (no '\n' at the end), and you input it into
an int, eofbit will be set. (There are historical reasons for
this, and Alf is right that it would be nice to be able to have
separate exceptions for a format error and for an absense of
data because of end of file.)
Exceptionally, of course, you may feel sure enough about the
format of the file to decide that a format error *is* an
exceptional condition. (If, for example, it is, or should be, a
file written by your program sometime earlier.) You know, for
example, that it contains three integers. In such cases, it
might make sense to request exceptions for failbit as well. And
of course, you will get the exception if the file doesn't
actually contain three integer values.
I hadn't read this before writing what I did above, but it sounds like
we pretty much agree on it being a possiblity under just the right
circumstances -- and even picked essentially identical circumstances at
that...
Except that the exception you want is on failbit, and not
eofbit.
I think it comes down to this: output is somewhat hard, but
input is drastically harder. While I suspect iostreams could
be improved somewhat in this regard, I hope I'll be forgiven
if I have doubts about the possibility of doing a really
_good_ job portably at all.
Error handling is probably the point where iostream is the
weakest. Partially, of course, because there's very little you
can specify portably. But it really would have been possible to
have three real error bits, rather than two, and to have had an
eofbit which was only set when input actually failed because of
EOF, and not because eof was encountered during look-ahead.
(For historical reasons, something with the semantics of the
current eofbit is also needed. Once streambuf::sgetc() has
returned EOF, you cannot reliably call it again.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34