lafore_robert_objectoriented_programming_in_c

////////////////////////////////////////////////////////////////

file.read( reinterpret_cast<char*>(&pers), sizeof(pers) );

}

cout << endl; return 0;

}

Here’s some sample interaction with DISKFUN. The output shown assumes that the program has been run before and that two person objects have already been written to the file.

Enter person’s data:

Enter name: McKinley

Enter age: 22

12

AND S

F TREAMS

ILES

Streams and Files

In DISKFUN we use ios::app because we want to preserve whatever was in the file before. That is, we can write to the file, terminate the program, and start up the program again, and whatever we write to the file will be added following the existing contents. We use ios:in and ios:out because we want to perform both input and output on the file, and we use ios:binary because we’re writing binary objects. The vertical bars between the flags cause the bits representing these flags to be logically combined into a single integer, so that several flags can apply simultaneously.

We write one person object at a time to the file, using the write() function. When we’ve finished writing, we want to read the entire file. Before doing this we must reset the file’s current position. We do this with the seekg() function, which we’ll examine in the next section. It ensures we’ll start reading at the beginning of the file. Then, in a while loop, we repeatedly read a person object from the file and display it on the screen.

This continues until we’ve read all the person objects—a state that we discover using the eof() function, which returns the state of the ios::eofbit.

File Pointers

Each file object has associated with it two integer values called the get pointer and the put pointer. These are also called the current get position and the current put position, or—if it’s clear which one is meant—simply the current position. These values specify the byte number in the file where writing or reading will take place. (The term pointer in this context should not be confused with normal C++ pointers used as address variables.)

Often you want to start reading an existing file at the beginning and continue until the end. When writing, you may want to start at the beginning, deleting any existing contents, or at the end, in which case you can open the file with the ios::app mode specifier. These are the default actions, so no manipulation of the file pointers is necessary. However, there are times when you must take control of the file pointers yourself so that you can read from and write to

597

12

AND S

F TREAMS

ILES

AND

FILES

STREAMS

The tellg() Function

The first thing the program does is figure out how many persons are in the file. It does this by positioning the get pointer at the end of the file with the statement

infile.seekg(0, ios::end);

The tellg() function returns the current position of the get pointer. The program uses this function to return the pointer position at the end of the file; this is the length of the file in bytes. Next, the program calculates how many person objects there are in the file by dividing by the size of a person; it then displays the result.

In the output shown, the user specifies the second object in the file, and the program calculates how many bytes into the file this is, using seekg(). It then uses read() to read one person’s worth of data starting from that point. Finally, it displays the data with showData().

Error Handling in File I/O

In the file-related examples so far we have not concerned ourselves with error situations. In particular, we have assumed that the files we opened for reading already existed, and that those opened for writing could be created or appended to. We’ve also assumed that there were no failures during reading or writing. In a real program it is important to verify such assumptions and take appropriate action if they turn out to be incorrect. A file that you think exists may not, or a filename that you assume you can use for a new file may already apply to an existing file. Or there may be no more room on the disk, or no disk in the drive, and so on.

Reacting to Errors

Our next program shows how such errors are most conveniently handled. All disk operations are checked after they are performed. If an error has occurred, a message is printed and the program terminates. We’ve used the technique, discussed earlier, of checking the return value from the object itself to determine its error status. The program opens an output stream object, writes an entire array of integers to it with a single call to write(), and closes the object. Then it opens an input stream object and reads the array of integers with a call to read().

//rewerr.cpp

//handles errors during input and output

const int MAX = 1000; int buff[MAX];

12

AND S

F TREAMS

ILES

specific information about a file I/O error. We’ve already seen some of these status flags at work in screen and keyboard I/O. Our next example, FERRORS, shows how they can be used in file I/O.

//ferrors.cpp

//checks for errors opening file

int main()

{

ifstream file; file.open(“a:test.dat”);

if( !file )

cout << “\nbad() = “ << file.bad() << endl; file.close();

return 0;

}

This program first checks the value of the object file. If its value is zero, the file probably could not be opened because it didn’t exist. Here’s the output from FERRORS when that’s the case:

Can’t open GROUP.DAT file = 0x1c730000 Error state = 4 good() = 0

eof() = 0 fail() = 4 bad() = 4

The error state returned by rdstate() is 4. This is the bit that indicates that the file doesn’t exist; it’s set to 1. The other bits are all set to 0. The good() function returns 1 (true) only when no bits are set, so it returns 0 (false). We’re not at EOF, so eof() returns 0. The fail() and bad() functions return nonzero, since an error occurred.

In a serious program, some or all of these functions should be used after every I/O operation to ensure that things went as expected.

12

AND S

F TREAMS

ILES