Built-In Types and Standard Strings in I/O

Most of the input and output you have seen so far moves simple values: whole numbers, decimal numbers, single characters, and text held in standard strings. Those values already have a meaning the library understands. Printing the number 42 or reading a word into a standard string requires nothing special from you, because the library already knows how to handle those kinds of values.

This raises a question the section is built around. What happens when the thing you want to read or write is a value of a type you designed yourself? A program that tracks a list of people, orders, or measurements will often build its own types to represent those records. It would be inconvenient if those records could never be printed or read. The section's answer is that they can, because the iostream library lets programmers define input and output for their own types.

It helps to think of the library as covering three kinds of values. The first is the built-in types, such as numbers and characters. The second is the standard string. The third 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 important 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 as well. The stream interface is the same shape for all three kinds of value; what differs is where the knowledge of the value's layout comes from.

To make the idea concrete, the source introduces a simple type named Entry. Its purpose is to represent one entry in a telephone book. The source uses this type as the example for defining input and output on a programmer-defined type, so it is the thread to follow through the rest of this topic.

Notice why a type like Entry is a natural candidate. A single telephone book entry is a bundle of related information about one person. No built-in type describes that bundle as a whole, so a programmer creates a type to represent it. Once that type exists, it is reasonable to want to print an entry to the screen or read one in from a file. That desire is exactly what the iostream extension is meant to support.

Picture a telephone book entry moving between your program and the outside world. When it is printed, the program turns the record into characters that a person or a file can display. When it is read, characters coming from an input source must be turned back into the record's parts. For built-in types the library already knows how to do this 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.

The title of this section names two topics: handling I/O errors and handling end-of-file. Reading a record from a stream can go wrong. The input may be missing, malformed, or may run out before the record is complete. Those situations are what the title refers to.

The connection is still worth keeping in mind. Reading a custom record is the situation where a failed or 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.