Sign in to follow this  
Red Ghost

MinGW C++ ifstream problem

Recommended Posts

Red Ghost    368
Hi, I have ported a Win32 program developped under Borland C++ 5.01 into MinGW C++ 3.3.0 (using IDE Dev C++). I solved all bugs and warnings in MinGW C++ and the program compiles fine (no bugs no warnings). The program is monothread. In this program the user may open any number of files of a certain type. These files have a header that identify their type and version. The pseudo-code for file opening is the following: 1- use Windows IO common dialog to retrieve the path and name of the file to open 2- check wether the file exists on the drive or not (if not send an error msg and exit) 3- open file using ifstream and read in the file header struct (using the ifstream read method) 4- check the file header components __a-> if the header.type is not of the allowed type (send an error msg and exit) __b-> if the header.version is superior to the max version allowed (send an error msg and exit) __c-> if the header.version is inferior to the max version allowed (set up some internal flags for processing) __d-> process the file and load data into a structure. 5- close the ifstream and hand back control to the main procedure. On to the bug (always reproduced): When I open a first file, the program behaves normally and completes the pseudo-code above. When I open a second file, the program does not read in the file header struct ! - the filename is correct. - the ios::bad bit is not set (meaning ifstream opened correctly the file) I just don't understand why it works the first time and not the second. I searched the MinGW FAQ and forums to see wether there was a referenced bug to no avail. I googled to see if anybody reported such a problem and found nothing. Note that the program compiled under Borland C++ 5.01 performs normally and always opens the files. Does anybody have had the same experience or a clue ? Thanks. Red Ghost.

Share this post


Link to post
Share on other sites
sit    170
do you use the same ifstream object to open the second file?

if so, once you've reached eof you need to do fileobj.clear() to clear the bits, before a valid open can be done

this is also true if you do an invalid open and want to try again

furthermore, I believe this behavior is defined and expected [normal]

Share this post


Link to post
Share on other sites
Red Ghost    368
Thank you for your answer. I just reached at the same time the same conclusion.
Yes I do use the same stream object and I did not clear the bits before opening the next file(silly me).
I have traced that when I reach file.eof the eof and the fail bits are set.
Thus when opening the next file, the fail bit is not reset.

Thank you for your answer.
Red Ghost.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this