Re: Error with ifstream and exceptions
On Feb 8, 6:47 pm, Marco <net...@lavabit.com> wrote:
On 2011-02-08 James Kanze <james.ka...@gmail.com> wrote:
[...]
Thanks for the explanations about the bits.
while ( getline( fileIn, line ) || fileIn.gcount() != 0 ) {
if ( !fileIn ) {
// incomplete last line...
}
// ...
}
I don't see the need to write this. I always get the last line.
// incomplete last line...
never gets executed. If I understand you correctly this line should be
executed for instance if I read in a file that just contains =BBhello=AB.=
The
getline fails because eof is seen. But getline sees the =BBhello=AB with =
my
construct without gcount().
That was my mistake. I was thinking of some other unformatted
read functions. This is one of the rare cases where it might
make sense to test for eof after a successful read, e.g.:
while ( getline( fileIn, line ) ) {
if ( fileIn.eof() ) {
// incomplete last line...
}
// ...
}
[...]
I'd write something like:
std::ifstream fileIn( name );
if ( !fileIn.open() )
throw ...
As I wrote before: if(!fileIn.open()) does not work, since
open() has a void return type and it cannot be converted to
a bool. I can write
Sorry. That's a typo. By passing the filename to the
constructor, open has already been called, and the test should
use is_open():
if ( !fileIn.is_open() ) ...
fileIn.open("file");
if (!fileIn) ... // This works
Also. In this particular case, I prefer the is_open, since it's
more explicit with regards to what I'm testing, but behind the
scenes:
if ( !fileIn.open() )
if ( fileIn.fail() )
if ( !fileIn )
all do exactly the same thing. (Immediately after an attempt to
open a file, at any rate. Before an attempt to open a file, the
last to will show success, although there is no file open, and
after other operations on an already open file, the last two
could show failure, although the file is open.)
[...]
I don't use windows, I used another editor. But I was not able
to trigger the problem you addressed. Maybe I did something
wrong. Just writing =BBHello=AB to a file shouldn't result in
a new line character, should it?
I was wrong, see above. But with regards to just writing
"hello" to a file, it all depends. Unix is very line oriented
in its text handling, and the editor I normally use (vim, both
in Windows and in Unix) is incapable of writing a file without
a final newline.
Another improvement that you'd want to make in production code:
before returning 0:
cout.flush();
if ( !cout )
// Write error in the output...
This is more important than closing the input (here, since the
input will be automatically closed when fileIn goes out of
scope).
I read everywhere that this is not necessary, indeed but one
should do it nonetheless. I put it, so it's clear when the
file is closed.
For input, it's not too critical.
If for some reason (e.g. disk full) there has been
a write error, the output data will not be complete, and your
user should definitely be informed.
cout.flush() writes everything what is left in the buffer to
the screen (or to a file when the output is redirected) if I'm
not mistaken.
That's a good first approximation.
But what does !cout mean,
if ( !cout )
is just the opposite of
if ( cout )
Streams are designed to convert implicitly and support operators
so that they can be used more or less as boolean values, at
least in if's and such. If the result of the conversion is
considered true, all preceding io has succeeded. If the result
is false, an "error" has occured.
that cout fails?
That depends on the system. The most frequent case is when the
output is going to disk, and the disk if full.
But
how can I inform the user if I cannot do a cout?
That's what cerr is for. And the final return status. Under
Unix, one common idiom is:
prog input > tmp && mv tmp input
prog (your program) reads input, and writes the transformed data
to a temporary file. If prog succeeds (returns 0 or
EXIT_SUCCESS), you then replace your original file with the
output. But only if prog succeeds; you don't want to replace
the original file if you've lost half of it, because the disk
was full.
When should cout fail?
Disk full is probably the most frequent case. Or a loss of
connection to the machine on which you were working. Or
whatever. cout can go pretty much anywhere, and there are all
sorts of possible failures.
cout writes to the screen, not to the disk.
Cout writes to where ever the OS wants it to. And the OS's
I use allow you to choose between the screen, a file, a pipe to
another process, and a few other odds and ends. If you're
writing to the screen, when working on a remote machine, and
loose the connection, it's generally not important. If you're
writing to a pipe, and the reader disappears, no problem either.
But if you're writing to disk... See above.
--
James Kanze