Designing Classes for Input and Output

Most of the input and output you have met so far moves simple values: whole numbers, decimal numbers, single characters, and text held in standard strings. The library already understands these values, so printing one is routine. Programs quickly outgrow that list, though. A program that tracks people, orders, or measurements will often build its own types to represent each record, and those records are exactly what you will want to print or read.

It helps to sort the values that flow through iostream into three groups. The first group is the built-in types, such as numbers and characters. The second group is the standard string. The third group is the programmer's own types. The source treats the first two as the starting point and then extends the same idea to the third. The key point is that the library is not fixed to a predefined list of types. A type you write can take part in input and output too.

The source uses a simple type named Entry as its running example. An Entry represents one entry in a telephone book. A single entry is a bundle of related information about one person, and no built-in type describes that bundle as a whole. That is why a programmer creates a type for it. Once the type exists, it is reasonable to want to print an entry to the screen or read one in from a file. Supporting that desire is exactly what the extension of iostream to programmer-defined types is meant to do.

Picture an Entry moving from your program to the outside world. On the way out, the program must turn the record into characters that a person or a file can display. For built-in types the library already knows how to make that conversion. For an Entry, the programmer has to supply the rules, because the library has no built-in knowledge of what an Entry looks like. Defining input and output for a programmer-defined type therefore means teaching the stream machinery how to handle that new type. The library supplies the machinery, and your code supplies the knowledge.

In C++, that teaching is usually done by writing an overloaded output operator, written as operator<<, for the custom type. The source states the capability plainly but does not show the code, so the following example is an original illustration of the idea rather than the book's own implementation.

Trace the flow in the diagram. The expression cout << e hands the stream and the Entry to the user-defined function. That function reads the name and number fields and writes them to the stream. Control moves from the library to your rule and back again, and the printed characters are the only thing that reaches the output.

A single output statement often contains several items separated by <<. The expression os << a << b does not run as one operation. It is a sequence of calls. Each call writes one item to the stream and returns the stream, and that returned stream becomes the left operand of the next <<. This is why the function in the earlier example ends with return os. Without that return, the next item in the chain would have no stream to write to.

Reading an Entry from input runs the process in the opposite direction. Characters coming from an input source must be turned back into the record's parts. The library already performs this conversion for built-in types, so for an Entry the programmer must again supply the rules. In C++ this is typically written as an overloaded input operator, operator>>, which pulls values from the stream and assigns them to the fields of the object. The order of those pulls matters, because each value must be read in the same order the record was written. The source introduces this capability in general terms; the exact input code is not part of the excerpt available here.

The connection is still worth keeping in mind. Reading a custom record is the situation where an incomplete read matters most, because a single Entry usually depends on several pieces of input arriving together. Understanding how a custom type is read is therefore the groundwork for understanding how a read can fail.