ifstream::open(), close(), and EOF
Michael Klatt
doesn't clear an EOF state? I am reading a series of input files
inside a loop using the same ifstream. Unless I explicitly clear the
stream before trying to read from it again it only works the first
time through the loop. Why doesn't calling open() and/or close()
clear any stream errors?
#include <fstream>
#include <iostream>
using namespace std;
int main()
{
ifstream file;
for (int i = 0; i < 3; ++i)
{
file.open("input.txt");
if (file.eof()) cout << "EOF\n";
int i;
while (file >> i)
{
cout << i << "\n";
}
file.close();
file.clear(); // why do I have to explicitly do this?
}
return 0;
}
input.txt:
----------------
1
2
3
-----------------
If I explicitly clear the stream I get the expected output:
1
2
3
1
2
3
1
2
3
If I don't I get this:
1
2
3
EOF
EOF
Mike Wahler
Michael Klatt <mdk...@ou.edu> wrote in message
news:2cb75565.03022...@posting.google.com...
> Am I correct in assuming that calling open() or close() on an ifstream
> doesn't clear an EOF state?
Correct.
> I am reading a series of input files
> inside a loop using the same ifstream. Unless I explicitly clear the
> stream before trying to read from it again it only works the first
> time through the loop.
That's because an end-of-file condition not only sets
eofbit, but failbit as well. When failbit is set, i/o
operations will fail.
> Why doesn't calling open() and/or close()
> clear any stream errors?
Because it's not defined to do so?
>
> #include <fstream>
> #include <iostream>
>
> using namespace std;
>
> int main()
> {
> ifstream file;
> for (int i = 0; i < 3; ++i)
> {
> file.open("input.txt");
You should check if the open succeeded or not before
proceeding.
> if (file.eof()) cout << "EOF\n";
> int i;
> while (file >> i)
> {
> cout << i << "\n";
> }
> file.close();
> file.clear(); // why do I have to explicitly do this?
You've got it backwards, write:
file.clear();
file.close();
'clear()' must be called before more operations with
this stream, because an end of file condition sets failbit.
> }
> return 0;
> }
>
>
> input.txt:
> ----------------
> 1
> 2
> 3
> -----------------
>
> If I explicitly clear the stream I get the expected output:
> 1
> 2
> 3
> 1
> 2
> 3
> 1
> 2
> 3
>
> If I don't I get this:
> 1
> 2
> 3
> EOF
> EOF
I'd expect this behavior.
Another option would be to create your ifstream object
inside a loop, in which case it will be destroyed and
recreated (with state flags cleared) for each loop
iteration.
-Mike
Michael Klatt
> > clear any stream errors?
>
> Because it's not defined to do so?
That seems counterintuitive to me, but what do I know?
> You've got it backwards, write:
>
> file.clear();
> file.close();
>
>
>
>
> 'clear()' must be called before more operations with
> this stream, because an end of file condition sets failbit.
>
Ahhh, now the reasoning makes sense.
On a related matter, does calling open() on an already open fstream
cause a resource leak, or does open() automatically close the existing
file?
file.open("file1");
file.close(); // is this necessary?
file.open("file2");
Mike Wahler
Michael Klatt <mdk...@ou.edu> wrote in message
news:2cb75565.03022...@posting.google.com...
> "Mike Wahler" <mkwa...@mkwahler.net> wrote in message
news:<b3lpdn$bld$1...@slb2.atl.mindspring.net>...
> > Michael Klatt <mdk...@ou.edu> wrote in message
> > news:2cb75565.03022...@posting.google.com...
> >
> > > Why doesn't calling open() and/or close()
> > > clear any stream errors?
> >
> > Because it's not defined to do so?
>
> That seems counterintuitive to me, but what do I know?
>
>
> > You've got it backwards, write:
> >
> > file.clear();
> > file.close();
> >
> >
> >
> >
> > 'clear()' must be called before more operations with
> > this stream, because an end of file condition sets failbit.
> >
>
> Ahhh, now the reasoning makes sense.
>
> On a related matter, does calling open() on an already open fstream
> cause a resource leak,
No.
> or does open() automatically close the existing
> file?
No.
If you call open for a file stream for which is_open() returns
true, failbit is set.
>
> file.open("file1");
> file.close(); // is this necessary?
Yes.
> file.open("file2");
I really think you need some books (or if you have some,
better ones.)
-Mike
Michael Klatt
> Michael Klatt <mdk...@ou.edu> wrote in message
> news:2cb75565.03022...@posting.google.com...
> > "Mike Wahler" <mkwa...@mkwahler.net> wrote in message
> news:<b3lpdn$bld$1...@slb2.atl.mindspring.net>...
> > > Michael Klatt <mdk...@ou.edu> wrote in message
> > > news:2cb75565.03022...@posting.google.com...
> > >
>
> I really think you need some books (or if you have some,
> better ones.)
>
> -Mike
I've got TC++PL (Stroustrup) and The C++ Standard Library (Josuttis),
among others. The problem with both of these books is that sometimes
you really have to know where to look to find the right answer, like
looking up a word in the dictionary that you don't know how to spell.
I looked up 'fstream' in the Josuttis index and didn't find much
information. This morning I had the "brilliant" idea to actually look
under 'open' and found most of the answers you gave me right away.
Thanks for your help.
Homer Meyer
"Michael Klatt" <mdk...@ou.edu> wrote in message
news:2cb75565.03022...@posting.google.com...
> "Mike Wahler" <mkwa...@mkwahler.net> wrote in message
news:<b3m7jl$gvv$1...@slb2.atl.mindspring.net>...
> > Michael Klatt <mdk...@ou.edu> wrote in message
> > news:2cb75565.03022...@posting.google.com...
> > > "Mike Wahler" <mkwa...@mkwahler.net> wrote in message
> > news:<b3lpdn$bld$1...@slb2.atl.mindspring.net>...
> > > > Michael Klatt <mdk...@ou.edu> wrote in message
> > > > news:2cb75565.03022...@posting.google.com...
> > > >
>
> >
> > I really think you need some books (or if you have some,
> > better ones.)
> >
> > -Mike
>
> I've got TC++PL (Stroustrup) and The C++ Standard Library (Josuttis),
> among others. The problem with both of these books is that sometimes
> you really have to know where to look to find the right answer, like
> looking up a word in the dictionary that you don't know how to spell.
> I looked up 'fstream' in the Josuttis index and didn't find much
> information. This morning I had the "brilliant" idea to actually look
> under 'open' and found most of the answers you gave me right away.
> Thanks for your help.
Sometimes, I wonder if using an index in the back of a book is becoming
somewhat of a lost art. I pulled out my copy of Josuttis, and looked up
"fstream" in the index. It directs the reader to page 627 which is the
beginning of section 13.9 on file streams. So I turn pages scanning
through the section looking for information on "open", I find it in a
matter of seconds on pages 633 and 634. The six or seven pages in between
have lots of useful information that it wouldn't hurt to read through,
including information on the file flags (in, out, app, ate, trunc, binary)
that can be passed into the open member function.
It puzzles me, because I see complaints about the indexes in Stroustrup and
Josuttis posted in this newsgroups fairly often, but I have always found
both indexes to be quite good.
Neil Butterworth
"Homer Meyer" <ho...@cqg.com> wrote in message
news:v5vcds2...@news.supernews.com...
I think the Josuttis index is probably the best I've ever come across in a
technical book. I think the Stroustrup index is one of the worst.
NeilB
Michael Klatt
> > among others. The problem with both of these books is that sometimes
> > you really have to know where to look to find the right answer, like
> > looking up a word in the dictionary that you don't know how to spell.
> > I looked up 'fstream' in the Josuttis index and didn't find much
> > information. This morning I had the "brilliant" idea to actually look
> > under 'open' and found most of the answers you gave me right away.
> > Thanks for your help.
>
> Sometimes, I wonder if using an index in the back of a book is becoming
> somewhat of a lost art. I pulled out my copy of Josuttis, and looked up
> "fstream" in the index. It directs the reader to page 627 which is the
> beginning of section 13.9 on file streams. So I turn pages scanning
> through the section looking for information on "open", I find it in a
> matter of seconds on pages 633 and 634. The six or seven pages in between
> have lots of useful information that it wouldn't hurt to read through,
> including information on the file flags (in, out, app, ate, trunc, binary)
> that can be passed into the open member function.
>
> It puzzles me, because I see complaints about the indexes in Stroustrup and
> Josuttis posted in this newsgroups fairly often, but I have always found
> both indexes to be quite good.
Part of the problem is comp.lang.c++ itself. The quickness and
quality of answers here encourages laziness. I was obviously guilty
of that with this thread. Almost always, though, the answers here are
better than than what you'll find in any book.