Re: Stream states questions
* James Kanze:
On Sep 9, 3:03 am, "Alf P. Steinbach" <al...@start.no> wrote:
That aside, if the streams are set up to generate
exceptions on failure, then you're not guaranteed to avoid exception on
detecting end of file, which makes that feature rather useless.
Have you ever actually tried it? If you're stupid enough to
request an exception on eofbit, you'll get one whenever the
implemention reaches eof. If you ask for one on failbit (not
usually recommended either, but useful in some cases), then
you'll get one on failbit, and only on failbit. And if you ask
for one on badbit (highly recommended), then you'll get one on
badbit, and only on badbit.
Ah, language, James, language! I don't know where you got the idea that
I might be stupid. After all, I'm pretty smart. :-)
And of course I've tried it, and you do risk getting an exception on
(first detection of) EOF if you ask for exceptions on failbit. And if
you only ask for exceptions on badbit, you're not guaranteed to get an
exception when an input operation fails to read what you requested[1],
so that's not exceptions on failure. In short, to use your chosen
descriptive word here, it's "stupid", and you're wrong.
Treating detection of EOF as an exceptional failure (and more generally,
coupling detection of EOF to failure to read what's asked for) is very
ungood design. For that matter, sticky EOF state, hidden modes, silent
failure, etc. etc. associated with this particular little aspect of
iostreams, it's so bad that even "badbit" and "failbit" don't adequately
convey how badly it fails.
Also note that operator void* (used for conversion to logical boolean)
and operator! (ditto) just check the failbit.
In other words, let s be a stream object, then if(s){...} is not the
same as if(s.good()){...}, it's the same as if(!s.fail()){...}. It's
all very perplexing. But, remember, you can just say NO to iostreams.
Also, if a stream's bad() is true, doesn't that imply that
fail() should be true in real world?
I'd think so, but fail() only checks the failbit.
This is completely false.
Erik Wikstr?m corrected that misimpression earlier, else-thread. Now
you're so upset that you're harking on and on about it, as if it
mattered anything at all, and as if it was an additional point every
time you mention it... You're grasping at a straw here, by going to
personal attack and drawing the grandest conclusions from nothing,
[snip]
In sum, you're arguing about something you know nothing about.
Cheers, & hth.,
- Alf
Notes:
[1] E.g. this program
<code>
#include <iostream>
#include <ostream>
#include <cstddef>
#include <stdexcept>
#include <string>
void cppMain()
{
using namespace std;
cin.exceptions( ios::badbit ); // James' recommendation.
// Are we guaranteed that non-throwing input = successful input?
while( !cin.fail() )
{
int x;
cin >> x;
cout << "* " << x << endl;
}
}
int main()
{
try
{
cppMain();
return EXIT_SUCCESS;
}
catch( std::exception const& x )
{
std::cerr << "!" << x.what() << std::endl;
return EXIT_FAILURE;
}
}
</code>
produces with MSVC 7.1 and input 666 plus next line EOF,
<output>
666
* 666
^Z
* 666
</output>
where the last line exemplifies the statement that referred to this note.