This particular page contains an introduction to the use of files.

9 Simple use of files

9.1 Dealing with more data

While some aspects of file use have to be left to later, it is worth introducing simple ways of using files. Many of the later example programs will be organized as shown in Figure 9.1.

Figure 9.1 Programs using file i/o to supplement standard input and output.

These programs will typically send most of their output to the screen, though some may also send results to output files on disks. Inputs will be taken from file or, in some cases, from both file and keyboard. (Input files can be created with the editor part of the integrated development environment used for programming, or can be created using any word processor that permits files to be saved as "text only".)

Text files

Input files (and any output files) will be simply text files. Their names should be chosen so that it obvious that they contain data and are not "header" (".h") or "code" (".cp") files. Some environments may specify naming conventions for such data files. If there are no prescribed naming schemes, then adopt a scheme where data files have names that end with ".dat" or ".txt".

Binary files

Data files based on text are easy to work with; you can always read them and change them with word processors etc. Much later, you will work with files that hold data in the internal binary form used in programs. Such files are preferred in advanced applications because, obviously, there is no translation work (conversion from internal to text form) required in their use. But such files can not be read by humans.

"Redirection of input and output".

Some programming environments, e.g. the Unix environment, permit inputs and outputs to be "redirected" to files. This means that:

1. you can write a program that uses cin for input, and cout for output, and test run it normally with the input taken from keyboard and have results sent to your screen, then
2. you can subsequently tell the operating system to reorganize things so that when the program needs input it will read data from a file instead of trying to read from the keyboard (and, similarly, output can be routed to a file instead of being sent to the screen).

The program will attach these filestream objects to named files and then use them for input and output operations.

9.2 Defining filestream objects

fstream.h header file

The header file fstream.h contains the definitions of these objects. There are basically three kinds:

• ifstream objects --- these can be used to read data from a named file;
• ofstream objects --- these can be used to write data to a named file;
• fstream objects --- these are used with files that get written and read (at different times) by a program.

The fstream objects, used when files are both written and read, will not be encountered until much later examples (those dealing with files of record structures).

A program that needs to use filestreams must include both the iostream.h and fstream.h header files:

#include < iostream.h>
#include < fstream.h>

int main()
{
	   ...;

ifstream objects

ifstream objects are simply specialized kinds of input stream objects. They can perform all the same kinds of operations as done by the special cin input stream, i.e. they can "give" values to integers, characters, doubles, etc. But, in addition, they have extra capabilities like being able to "open" and "close" files.

ofstream objects

Similarly, ofstream objects can be asked to do all the same things as cout - print the values integers, doubles etc - but again they can also open and close output files.

The declarations in the file fstream.h make ifstream, ofstream, and fstream "types". Once the fstream.h header file has been included, the program can contain definitions of variables of these types.

Often, filestream variables will be globals because they will be shared by many different routines in a program; but, at least in the first few examples, they will be defined as local variables of the main program.

There are two ways that such variables can be defined.

Defining a filestream attached to a file with a known fixed name

#include < iostream.h>
#include < fstream.h>

int main()
{
    ifstream   input("theinput.txt", ios::in);
    ...

The alternative form of definition is:

Defining a filestream that will subsequently be attached to a selected file

#include < iostream.h>
#include < fstream.h>

int main()
{
    ifstream   in1;
    ...

The open request uses a filename (and the ios::in token). The filename will be a character string; usually a variable but it can be a constant (though then one might as well have used the first form of definition). With a constant filename, the code is something like:

Call to open()

#include < iostream.h>
#include < fstream.h>

void main()
{
    ifstream   in1;
    ...
    in1.open("file1.txt", ios::in);
    // can now use in1 for input ...
    ...

9.3 Using input and output filestreams

#include < iostream.h>
#include < fstream.h>

void main()
{
	ifstream   input("theinput.txt", ios::in);
	long l1, l2; double d3; char ch;
	...
	input >> d3; // read a double from file
	...
	input >> ch; // read a character 
	...
	input >> l1 >> l2; // read two long integer

#include < iostream.h>
#include < fstream.h>

void main()
{
	// create an output file
	ofstream out1("results.txt", ios::out);
	int i; double d;
	...
	// send header to file
	out1 << "The results are :" << endl; 	...
	for(i=0;i < 100; i++) {
		...
		// send data values to file
		out1 << "i : " << i << ",    di " << d << endl;
		...
		}
	out1.close(); //finished, close the file.

out1.close();

9.4 Stream' states

It is easy to get a program to go completely wrong if it tries to take more input data from a filestream after some transfer operations have already failed. The program may "crash", or may get stuck forever in a loop waiting for data that can't arrive, or may continue but generate incorrect results.

Operations on filestreams should be checked by using the normal stream functions good(), bad(), fail(), and eof(). These stream functions can be applied to any stream, but just consider the example of an ifstream:

ifstream in1("indata.txt", ios::in);

in1.good()		returns "True" (1) if in1 is OK to use
in1.bad()		returns "True" (1) if last operation on
			in1 failed and there is no way to recover
			from failure
in1.fail()		returns "True" (1) if last operation on
			in1 failed but recovery may be possible 
in1.eof()		returns "True" (1) if there are no more
			data to be read.

ifstream in1("indata.txt", ios::in);
long	val1, val2;
in1>> val1 >> val2;

if(in1.fail()) {
	cout << "Sorry, can't read that file" << endl;
	exit(1);
	}

Naturally, this being C++ there are abbreviations. Instead of phrasing a test like:

if(in1.good()) 
	...

if(in1)
	...

if(!in1)

if(in1.bad())

One check should always be made when using ifstream files for input. Was the file opened?

There isn't much point continuing with the program if the specified data file isn't there.

The state of an input file should be checked immediately after it is opened (either implicitly or explicitly). If the file is not "good" then there is no point in continuing.

A possible way of coding the check for an OK input file should be as follows:

#include < stdlib.h>
#include < iostream.h>
#include < fstream.h>

int main()
{
	ifstream in1("mydata.txt", ios::in);
	switch(in1.good()) {
case 1:
	cout << "The file is OK, the program continues" << endl;
	break;
case 0:
	cout << "The file mydata.txt is missing, program"
			" gives up"  << endl;
        exit(1);
     } 
    ...

Implementations of C++ aren't totally standardized. Most implementations interpret any attempt to open an input file that isn't there as being an error. In these implementations the test in1.good() will fail if the file is non-existent and the program stops.

Unfortunately, some implementations interpret the situation slightly differently. If you try to open an input file that isn't there, an empty file is created. If you check the file status, you are told its OK. As soon as you attempt to read data, the operation will fail.

The following style should however work in all environments:

int main()
{
	ifstream in1("mydata.txt", ios::in | ios::nocreate);
	switch(in1.good()) {
		...

9.5 Options when opening filestreams

ios::in		Open for reading.
ios::out		Open for writing.
ios::ate		Position to the end-of-file.
ios::app		Open the file in append mode.
ios::trunc		Truncate the file on open.
ios::nocreate	Do not attempt to create the file if it
				does not exist.
ios::noreplace	Cause the open to fail if the file exists.
ios::translate	Convert CR/LF to newline on input and
				vice versa on output.

Typical combinations are:

ios::in | ios::nocreate		open if file exists,
						fail otherwise
ios::out | ios::noreplace	open new file for output,
						fail if filename 
						already exists
ios::out | ios::ate		(re)open an existing output
						file, arranged so
						that new data added
						at the end after
						existing data
ios::out | ios::noreplace | ios::translate
					open new file, fail if name
						exists, do newline
						translations 
ios::out | ios::nocreate | ios::trunc
					open an existing file for
						output, fail if file
						doesn't exist, throw
						away existing
						contents and start
						anew

"Bitmasks"

The tokens ios::in etc are actually constants that have a single bit set in bit map. The groupings like ios::open | ios::ate build up a "bitmask" by bit-oring together the separate bit patterns. The code of fstream's open() routines checks the individual bit settings in the resulting bit mask, using these to select processing options. If you want to combine several bit patterns to get a result, you use an bit-or operation, operator |.

Don't go making the following mistakes!

ofstream	out1("results.dat", ios::out || ios::noreplace);
ifstream	in1("mydata.dat", ios::in & ios::nocreate);

The second error is a conceptual one. The programmer was thinking "I want to specify that it is an input file and it is not to be created". This lead to the code ios::in & ios::nocreate. But as explained above, the token combinations are being used to build up a bitmask that will be checked by the open() function. The bit-and operator does the wrong combination. It is going to leave bits set in the bitmask that were present in both inputs. Since ios::in and ios::nocreate each have only one bit, a different bit, set the result of the & operation is 0. The code is actually saying in1("mydata.dat", 0). Now option 0 is undefined for open() so this isn't going to be too useful.

9.6 When to stop reading data?

Sentinel data

The sentinel data approach was described in section 8.5.1. A particular data value (something that cannot occur in a valid data element) is identified (e.g. a 0 height for a child). The input loop stops when this sentinel value is read. This approach is probably the best for most simple programs. However, there can be problems when there are no distinguished data values that can't be legal input (the input requirement might be simply "give me a number, any number").

Count

The next alternative is to have, as the first data value, a count specifying how many data elements are to be processed. Input is then handled using a for loop as follows:

int		num;
ifstream	in1("indata.txt", ios::in);
...
// read number of entries to process
in1 >> num;
for(int i = 0; i < num; i++) {
	// read height and gender of child
	char gender_tag;
	double height;
	cin >> height >> gender_tag;
	...
	}

eof()

The third method uses the eof() function for the stream to check for "end of file". This is a sort of semi-hardware version of a sentinel data value. There is conceptually a mark at the end of a file saying "this is the end". Rather than check for a particular data value, your code checks for this end of file mark.

This mechanism works well for "record structured files", see Figure 9.2A. Such files are explained more completely in section 17.3. The basic idea is obvious. You have a file of records, e.g. "Customer records"; each record has some number of characters allocated to hold a name, a double for the amount of money owed, and related information. These various data elements are grouped together in a fixed size structure, which would typically be a few hundred bytes in size (make it 400 for this example). These blocks of bytes would be read and written in single transfers. A record would consist of several successive records.

Figure 9.2 Ends of files.

Three "customer records" would take up 1200 bytes; bytes 0...399 for Customer-1, 400...799 for Customer-2 and 800...1199 for Customer-3. Now, as explained in Chapter 1, file space is allocated in blocks. If the blocksize was 512 bytes, the file would be 1536 bytes long. Directory information on the file would specify that the "end of file mark" was at byte 1200.

You could write code like the following to deal with all the customer records in the file:

ifstream	sales("Customers.dat", ios::in | ios::nocreate);
if(!sales.good()) {
	cout << "File not there!" << endl;
	exit(1);
	}
while(! sales.eof()) {
	read and process next record
	}

The eof() scheme is a pain with text files. The problem is that text files will contain trailing whitespace characters, like "returns" on the end of lines or tab characters or spaces; see Figure 9.2B. There may be no more data in the file, but because there are trailing whitespace characters the program will not have reached the end of file.

If you tried code like the following:

ifstream	kids("theHeights.dat", ios::in | ios::nocreate);
if(!kids.good()) {
	cout << "File not there!" << endl;
	exit(1);
	}
while(! kids.eof()) {
	double height;
	char gender_tag;
	kids >> height >> gender_tag;
	...
	}

But, the input statement kids >> height >> gender_tag; will now fail - there are no more data in the file. (The read attempt will have consumed all remaining characters so when the failure is reported, the "end of file" condition will have been set.)

You can hack around such problems, doing things like reading ahead to remove "white space characters" or "breaking" out of a loop if an input operation fails and sets the end of file condition.

But, really, there is no point fighting things like this. Use the eof() check on record files, use counts or sentinel data with text files.

9.7 More Formatting options

You won't make much use of these facilities, but there are odd situations where you will need them.

The following iomanip manipulators turn up occasionally:

setw(int)		sets a width for the next output
setfill(int)	changes the fill character for next output

hex		output number in hexadecimal format
dec		output number in decimal format

The following example uses several of these manipulators:

int main()
{
	int		number = 901;
	
	cout << setw(10) << setfill('#') << number << endl;
	cout << setw(6) << number << endl;
	
	cout << dec << number << endl;	
	cout << hex << number << endl;
	cout << setw(12) << number << endl;
	cout << setw(16) << setfill('@') << number << endl;

	cout << "Text" << endl;
	cout << 123 << endl;
	
	cout << setw(8) << setfill('*') << "Text" << endl;
	
	double d1 = 3.141592;
	double d2 = 45.9876;
	double d3 = 123.9577;
	
	cout << "d1 is " <<  d1 << endl;
	
	cout << "setting precision 3 " << setprecision(3)
			<< d1 << endl;
	cout << d2 << endl;
	cout << d3 << endl;
	cout << 4214.8968 << endl;
	
	return EXIT_SUCCESS;
}

#######901		901, 10 spaces, # as fill
###901		901, 6 spaces, continue # fill
901			just print decimal 901
385			print it as a hexadecimal number
#########385	hex, 12 spaces, # still is filler
@@@@@@@@@@@@@385	change filler 
Text		print in minimum width, no filler
7b			still hex output! 
****Text		print text, with width and fill
d1 is 3.141592	fiddle with precision on doubles
setting precision 3 3.142
45.988
123.958
4.215e+03

Alternative form of specification

There are alternative mechanisms that can be used to set some of the format options shown above. Thus, you may use

cout.width(8)	instead of	cout << setw(8)
cout.precision(4)	..		cout << setprecision(4)
cout.fill('$')	..		cout << setfill('$')

Other strange format options

There are a number of other output options that can be selected. These are defined by more of those tokens (again, these are actually defined bit patterns); they include:

ios::showpoint	(printing of decimal point and trailing 0s)
ios::showpos	(require + sign with positive numbers)
ios::uppercase	(make hex print ABCDE instead of abcde)

int main()
{
	long	number = 8713901;
	
	cout.setf(ios::showpos);
	cout << number << endl;
	cout.unsetf(ios::showpos);
	cout << number << endl;	
	cout << hex << number << endl;
	cout.setf(ios::uppercase);
	cout << number << endl;
	return EXIT_SUCCESS;
}

+8713901	positive sign forced to be present
8713901	normally it isn't shown
84f6ad	usual hex format
84F6AD	format with uppercase specified

Two related format controls are:

ios::left
ios::right

int main()
{
	cout.width(24);
	cout.fill('!');
	cout << "Hello" << endl;
	cout.setf(ios::left, ios::adjustfield);
	cout.width(24);
	cout << "Hello" << endl;
	cout.setf(ios::right, ios::adjustfield);
	cout.width(24);
	cout << "Hello" << endl;
	
	return EXIT_SUCCESS;
}

!!!!!!!!!!!!!!!!!!!Hello
Hello!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!Hello

You can specify whether you want doubles printed in "scientific" or "fixed form" styles by setting:

ios::scientific
ios::fixed

int main()
{
	double number1 = 0.00567;
	double number2 = 1.746e-5;
	double number3 = 9.43214e11;
	double number4 = 5.71e93;
	double number5 = 3.08e-47;
	
	cout << "Default output" << endl;
	
	cout << number1 << ", " << number2 << ", "  
			<< number3 << endl;
	cout << "      " << number4 << ", " << number5 << endl;
	
	cout << "Fixed style" << endl;
	
	cout.setf(ios::fixed, ios::floatfield);
	
	cout << number1 << ", " << number2 << ", " 
			<< number3 << endl;
//	cout << "      " << number4 ;
	cout << number5 << endl;
	
	cout << "Scientific style" << endl;
	cout.setf(ios::scientific, ios::floatfield);
	
	cout << number1 << ", " << number2 << ", "  
			<< number3 << endl;
	cout << "      " << number4 << ", " << number5 << endl;

	return EXIT_SUCCESS;
	}

Default output
0.00567, 1.746e-05, 9.43214e+11
      5.71e+93, 3.08e-47
Fixed style
0.00567, 0.000017, 943214000000
0
Scientific style
5.67e-03, 1.746e-05, 9.43214e+11
      5.71e+93, 3.08e-47

Maybe you should use stdio instead!

The various formatting options available with streams should suffice to let you layout any results as you would wish. Many programmers prefer to use the alternative stdio library when they have to generate tabular listings of numbers etc. You IDE environment should include documentation on the stdio library; its use is illustrated in all books on C.

Changing options for input streams

You don't often want to change formatting options on input streams. One thing you might occasionally want to do is set an input stream so that you can actually read white space characters (you might need this if you were writing some text processing program and needed to read the spaces and return characters that exist in an input file). You can change the input mode by unsetting the ios::skipws option, i.e.

cin.unsetf(ios::skipws);

The following program illustrates use of this control to change input options:

int main()
{
/*
Program to count the number of characters preceding a
period '.' character.
*/
	int	count = 0;
	char ch;
	
//	cin.unsetf(ios::skipws);
	cin >> ch;
	while(ch != '.') {
			count++;
			cin >> ch;
		}
	cout << endl;
	cout << "I think I read " << count << " characters."
			<< endl;	
	return EXIT_SUCCESS;
}

Finished, any questions? OK, go; wake that guy in the back row,
he must have been left here by the previous lecturer.

I think I read 95 characters.

I think I read 116 characters.

9.8 Example