The purpose of this appendix is to "review" certain features of C++ (and several other languages) that are used throughout the text, yet may be unfamiliar to readers. These notes are not comprehensive. Readers should consult on-line documentation, [STR], or any reasonably up-to-date reference for details.

A package is a named collection of declarations that may span several files (see chapter 1). A package defines the scope of the declarations it contains and may be separated into an interface package and an implementation package.

Modula-2 was developed by Nicolas Wirth in the late 1970s as the successor to Pascal. One of the main goals of Modula-2 was to support large software projects that could be quickly assembled out of reusable packages with well-defined interfaces. Wirth's formalization of packages, which he called modules, is lucid and well thought out, which is why we briefly look at them here. See [COOP] for more details.

A Modula-2 module (i.e., package) consists of a definition module and an implementation module. A definition module contains declarations of procedures, variables, constants, and types. An implementation module contains the definitions of the components declared in a corresponding definition module:

All modules must explicitly declare the definition modules they depend on using an import statement. Here's the general form of a definition module declaration. (Warning: all Modula-2 keywords use upper case letters only!)

The form of an implementation module is similar. A statement block at the end provides a place to initialize variables:

Here is an example of a definition module adapted from [COOP]. It groups functions and constants for computing areas of geometric figures:

The definitions of these functions are declared in the corresponding implementation module. Supporting functions, such as Square(), may also be defined in the implementation module. Of course only the functions declared in the definition module can be imported into other packages, so the scope of Square() will be limited to the implementation module:

Here is an example of a definition module that groups functions for computing volumes of surfaces:

In this case the corresponding implementation module imports the AREA module. This means that we can use the constant and functions declared in the AREA definition module, but their names must be qualified by "AREA", the name of their module.

Definition modules can also be formed by composing existing modules:

The corresponding implementation module is still required, although it is empty:

Here is the corresponding dependency graph:

The Java Development Kit (JDK) includes:

The JDK classes are partitioned into packages, sub-packages, and sub-sub-packages:

For example, clicking a button on a Java control panel creates and "fires" an action event object. Along with all of the other event classes, the ActionEvent class is declared in the AWTEvent package, which is declared inside the abstract windows toolkit package, awt. This package is declared inside java, the package of all pre-defined classes. Here is the syntax for the declaration of a reference to an action event object using the fully qualified name of the ActionEvent class:

We can avoid the need for fully qualified names by explicitly importing one package into another. For example, the import declaration:

placed at the top of a .java file tells the Java compiler to look in the java.awt.AWTEvent package for classes that are used but not defined in the file. We may now simply declare e by:

Of course Java programmers can create their own packages. For example, if a programmer wants to create a package called MyClasses, he simply declares:

at the top of each .java file containing declarations of classes belonging to the MyClasses package. Typically, all such files would be placed in the same directory.

If we forget to explicitly declare a class or member public, protected, or private, then by default, it has package scope.

C++ provides several types of scopes: global, file, class, and block. We can also create a package scope using a namespace declaration:

References to names outside of their namespace must be qualified using the scope resolution operator. For example, assume a function named jupiter() is declared in a namespace called Planet:

Clients of the Planet namespace must qualify calls to jupiter():

All of the declarations in the standard C++ library are contained in a namespace called std. This means names defined in the <iostream> header file, such as ostream, istream, cout, and cin must be qualified by "std::" when they are used by clients (see Programming Note A.3). For example, here's the official version of the Hello world program:

We will see how to avoid the std qualifier below.

In this example the Car namespace is declared in files ford.h and buick.h:

The linker isn't upset by what appears to be two separate declarations of the Car namespace. Instead, it regards the second "declaration" as a continuation of the first.

The implementations are in files ford.cpp and buick.cpp. Notice that the names of the member functions are qualified by the namespace name and the class name:

The test drivers are declared in file client.cpp:

test1() uses the qualified names for all items declared in the Car namespace:

test2() imports the name Car::test into its scope with a using declaration:

The using declaration is a bit like an import declaration, but it only allows the unqualified use of the test() functions from the point of the declaration to the end of the scope in which the declaration occurs. In this case the declaration occurs in a block scope. In other words, the test1() function must still qualify calls to test() with "Car::", even if it is declared after test2(). Also notice that we can't import one variant of the test() function but not the other.

test3() imports the entire Car namespace into its scope with the using directive:

Like the using declaration, the using directive only allows unqualified references to namespace names within the scope in which it occurs.

It is common to import the entire std namespace into a file scope to avoid the need to qualify every reference to a library type or object. Here's our new implementation of the Hello world program:

This using directive has file scope, which means that standard library names can only be used without qualification within the file.

Assume FarmJobs and OfficeJobs are namespaces:

We can create new namespaces from these using composition and selection. Composition creates a namespace by joining several existing namespaces:

Selection creates a new namespace by selecting items from existing namespaces:

A client can use Jobs and EasyJobs without knowledge of FarmJobs or OfficeJobs:

Like a header file, a namespace specifies an interface to clients and implementers. The implementer's interface contains all of the declarations:

As usual, we separate the implementation from the interface:

Assume we anticipate two types of clients: clerks and managers. Using selection, we can create client interfaces for each one:

We can eliminate the dependency of the manager interface, for example, on the register interface by providing implementations of the manager interface functions that delegate to the corresponding register functions:

Of course the implementation of the manager interface still depends on the register interface:

Keeping a large program (say more than 250 lines) in a single source file (e.g. a .cpp file) has several disadvantages:

For these reasons most programs are divided into several source files, each containing logically related declarations. Each source file is compiled separately, producing a file of machine language instructions called an object file (e.g., a .obj file in Windows and DOS):

It's the job of a program called a linker to link a project's object files together into a single executable file. The linker is responsible for associating all references to a name in one object file to the definition of the name, which might be in another object file. This process is called address resolution. Sometimes the definition of a name isn't in any of the project's object files. In this case the linker searches the standard C++ library (libcp.lib), the standard C library (libc.lib), and any special libraries specified by the programmer for the name's definition. (Only the definitions needed by the program are extracted from a library and linked into the program.)

If the name's definition still can't be found, the linker generates an unfriendly error message:

Multiple source file programs sound great, but there is a problem. While the compiler is willing to accept that a name can be used in a source file without being defined there (after all, its the linker's job to find the definition), the compiler must at least know the type of the name in order to perform type checking, variant selections, and offset calculations. But the compiler only compiles one file at a time. It knows nothing of the project's other source files; it can't be expected to go searching for a name's type the same way the linker searches for a name's definition. Regrettably, it is the programmer's duty to put type declarations of all names used but not defined in the file.

This job would be worse than it already is if it wasn't for the #include directive. A preprocessor directive is a command beginning with a # symbol that can appear in a source or header file. When a file is compiled, it is first submitted to the C/C++ preprocessor, which executes all directives. (Consult online help for a list of all directives.) Preprocessor directives usually alter the source file in some way:

For example, the #include directive takes a file name for its argument. When executed by the preprocessor, it replaces itself with the entire contents of the file. (Be careful, if the same directive is in the file, then an infinite loop can occur.)

How do we use #include to solve our problem? If a programmer creates a source file called util.cpp containing definitions that may be useful in other source files, the programmer also creates a header file called util.h containing the corresponding type declarations . A second source file, say main.cpp, that uses the definitions contained in util.cpp only needs to include the directive in order to be compiled:

Normally, util.h would also include type declarations needed by util.cpp, so util.cpp also includes util.h. Of course util.obj will still need to be available to the linker to create an executable.

C++ makes a distinction between definitions and declarations. Technically, a definition associates a name with a particular item such as a variable, function, or class, while a declaration merely associates a name with a type. We call items that can be named bindables, and an association between a name and a bindable a binding. Declarations are important to the compiler, while definitions are important to the linker. Here are some examples of definitions and declarations:

1. The definition:

associates the name x with an integer variable, while the declaration:

tells the compiler that x is the name of an integer variable, but not which one.

2. The definition:

associates the name square with a function that is parameterized by a double and that returns a double, while the declaration:

tells the compiler that square is the name of a function that is parameterized by a double and that returns a double, but not which one.

3. The definition:

associates the name Date with a class of objects, each containing three integer member variables named month, day, and year, while the declaration:

tells the compiler that Date is the name of a class, but not which one.

The terminology is a little confusing because associating a name to a bindable implicitly associates the name to a type, and therefore a definition is also a declaration. In other words, the definition:

is also a declaration, because it also tells the compiler that x is the name of an integer variable. However, the declaration:

is not a definition, because it doesn't bind the name x to any particular variable. In short, all definitions are declarations, but not vice versa. Let's call declarations that aren't definitions pure declarations.

The One-Definition Rule (ODR) states that a definition may only occur once in a C++ program, but a pure declaration can occur multiple times as long as the occurrences don't contradict each other. Therefore, pure declarations are often placed in header files, which may then be included multiple times in a program, but definitions should not be placed in header files.

However, some types of definitions are important to the compiler, too, and so, like pure declarations, these must be placed in header files that get included in every source file where they are needed. To accommodate these types of definitions, there are three exceptions to the One Definition Rule: types, templates, and inline functions may be multiply defined in a C++ program, provided three conditions are met:

Here are three ways of violating these conditions. (The example is borrowed from [STR].) See if you can spot them:

Example 1:

Example 2:

Example 3:

The second and third conditions are easy to live with, but insuring that a type definition will not occur multiple times in the same source file can be tricky. Suppose the definition of Date is contained in date.h, which is included in util.h:

Not knowing that util.h already includes date.h, the unwary author of main.cpp includes both files:

Unfortunately, this places two occurrences of the definition of Date in main.cpp, thus violating the condition that two type definitions can't occur in the same file.

To prevent this problem, header files can be conditionally included in a file. The usual condition is that a particular identifier hasn't been defined by the preprocessor, yet. The #ifndef /#endif directives are used to bracket the declarations that are conditionally included in this way. The identifier is usually defined immediately after the #ifndef directive using the #define directive. Thus the declarations are included exactly once. To prevent naming conflicts, the name of the identifier is formed from the name of the header file, replacing the period by an underscore and replacing lower case letters by upper case letters. Here's the new, safe version of date.h:

Since conditional inclusion is possible, why not ignore the One Definition Rule and place all definitions in header files? Well, conditional inclusion only prevents a header file from being included multiple times in a single source file. If our program has multiple source files, then it's still possible that a definition placed in a header file will occur multiple times within the program, which will cause a linker error.

We could restrict ourselves to a single source file, but a clever linker only extracts and links those definitions that are actually used into the executable file. If we include all definitions into a single source file, then they will appear in the executable whether they are used or not.

C++ comes with two standard libraries: the old C library (libc.lib), and the new C++ library (libcp.lib), which is logically divided into the stream library, and STL, the standard template library. Many implementations also include a pre-standard stream library for backward compatibility.

The declarations of the functions, variables, and types in the standard libraries are distributed among some 51 header files. We must include these header files where we use the items they declare. For example, if we will be using lists, strings, and streams, we must include:

The angle brackets tell the pre-processor to look in the "usual directory" for the header file. In theory, specifying the .h extension is optional for C++ library header files (i.e., for header files containing declarations of C++ library items). We can also drop the .h for C library header files, but in this case we add the letter "c" to the beginning of the file name to indicate that it is a C library header file. For example, the C library mathematical functions (sin(), pow(), fabs(), etc.) are declared in <math.h>, so we can either write:

or

See your online documentation or [STR] for a list of all 51 header files.

Namespaces were discussed in Programming Note A.1.3, where it was stated that the entire standard C++ library exists in a namespace called std, and therefore standard library names should be qualified by users:

Namespaces are useful for large programs, but for small programs they get a little tedious, so lazy programmers, like us, often join the entire std namespace to each file scope with a using directive:

Now we can refer to library items without the std qualification:

Namespaces are a relatively recent addition to C++, so of course they don't appear in the pre-standard stream libraries or the C library.

A container is actually a handle that manages a potentially complicated C-style data structure such as an AVL tree, hash table, or doubly linked list (see the Handle-Body idiom discussed in chapter 4). Fortunately, implementing these data structures is largely an academic exercise these days (but a good one). This is because the standard C++ library now comes with a collection of container templates called the Standard Template Library:

Here are some of the header files you need to include if you want to use STL containers:

A C string is simply a static or dynamic array of characters:

A C string literal is a sequence of characters bracketed by double quotes (backslash is the escape character):

C strings are always terminated by the NUL character (i.e., ASCII code 0). The standard C library provides functions for manipulating C strings. These are declared in <cstring>:

Because C strings don't check for out-of-range indices, and because they don't allocate and deallocate memory for themselves, programmers should use C++ strings instead. C++ strings are instances of the string class declared in <string>, which is part of the std namespace:

We can use C strings to initialize C++ strings:

The third C++ string, s3, is currently empty:

C++ strings can be read from an input stream using the extraction operator and written to an output stream using the insertion operator.

The size() and length() member functions both return the number of characters in a C++ string:

There are several ways to access the characters in a C++ string. One way is to use the subscript operator:

Unfortunately, the subscript operator doesn't check for index range errors. For this we must use the at() member function, which throws an out_of_range exception when the index is too large:

Assigning s2 to s3:

automatically copies s2 to s3. We can verify this by modifying the first character of s3:

then printing s2 and noticing that it is unchanged:

One of the best features of C++ strings is that they automatically grow to accommodate extra characters:

We don't need to bother with the awkward C library string manipulation functions. C++ strings can be compared and concatenated using infix operators:

There are also many member functions that can be used to find, extract, erase, and replace substrings:

The c_str() member function returns an equivalent C string which can be used by C library functions:

There are many more C++ string member functions. The reader should consult online documentation or [STR] for a complete list.

Iterators are similar to the smart pointers discussed in Chapter 4, only an iterator is an object that "points" to an element in a container, string, or stream. Like pointers, iterators can be incremented, decremented, compared, or dereferenced.

For example, we can traverse an array using index numbers:

but we could just as easily use a pointer to traverse the array:

We can traverse a C++ string using index numbers, too:

But we can't traverse a C++ string using an ordinary pointer, because a string is only a handle that encapsulates a C string. Instead, we must use an iterator to "point" at elements inside of a string.

Iterator declarations must be qualified by the appropriate container class:

This is because the iterator class for a container class is declared inside the container class declaration. For example:

This is done because iterators for strings might be quite different for iterators for lists, maps, and deques.

All container classes provide begin() and end() functions. The begin() function returns an iterator that points to the first element in the container. The end() function returns an iterator that points to a location just beyond the last element of the container.

C++ iterators can be regarded as an instantiation of the more general iterator design pattern:

Assume c is an STL container, x is a potential container element, and p is an iterator. Here are some of the most common operations:

STL vectors encapsulate dynamic arrays (see chapter 4). They automatically grow to accommodate any number of elements. The elements in a vector can be accessed and modified using iterators or indices.

To begin, let's provide a template for printing vectors, this will make a nice addition to our utility library. We use a constant iterator:

Here's how we declare an integer vector:

It's easy to add elements to the back of a vector:

It's also easy to remove elements from the back of a vector:

Of course we can use the subscript operator to access and modify vector elements:

The subscript operator is unsafe. It doesn't check for out of range indices. As with strings, we must us the vec.at(i) member function for safe access.

To insert or remove an item from any position in a vector other than the last, we must first obtain an iterator that will point to the insertion or removal position:

Next, we position p:

Finally, we insert the item using the insert() member function:

We follow the same procedure to remove an element:

STL lists encapsulate and manage linked lists. As before, we begin with a useful list writer. Only two changes are needed from the vector writer:

Here is how we declare two lists of strings:

We can add items to the front or rear of a list:

As with vectors, to insert an item into a list we first need an iterator pointing to the point of insertion:

Inserting an item into a list is more efficient than inserting an item into a vector. This is because logically consecutive elements of a dynamic array are also physically consecutive, while linked lists decouple logical and physical order. Therefore, inserting an item into a vector involves moving all elements above the insertion point to make space, while inserting an item into a list merely involves adjusting a few links.

On the other hand, pointing a vector iterator at an insertion point can be done by a single operation:

While pointing a list iterator at an insertion point involves multiple operations:

In general, C++ iterators belong to categories. While not classes, iterator categories are organized into a specialization hierarchy that can be described by the following class diagram:

List iterators are bidirectional. They inherit the ability to be incremented (by 1), compared, and dereferenced. In addition, they can be decremented (by 1). Vector iterators are random access. They inherit all of the functionality of bidirectional iterators, but they can be incremented or decremented by arbitrary amounts.

Removing an item from a linked list can also be done by pointing an iterator at the item to be removed:

But we can also remove the first occurrence of an item in the list by simply specifying the item to be removed:

The list<> template provides member functions for various useful list operations:

Consult your online documentation or [STR] for a complete list.

By themselves, deques (rhymes with "wrecks") are relatively useless. They are optimized for inserting and removing elements at either end, hence are ideal adaptees for stacks and queues. See the discussion on adapters in chapter 4 for details.

One of the most common and useful data structures is a table. For example, we used save and load tables in our persistence framework, and we used a prototype table in our implementation of the Prototype pattern. (See chapter 5 for details.)

A table is simply a list of pairs (i.e., the rows of the table) of the form:

KEY and VALUE can be any type, but no two pairs in a table have the same key. This requirement allows us to associatively search tables for a pair with a given key.

For example, a concordance is a table that alphabetically lists every word that appears in a document, together with the number of occurrences of that word. For example, The Harvard Concordance to Shakespeare lists every word ever written by the Bard. It is 2.5 inches thick and lists about 29,000 different words! (The King James Bible only uses 6000 different words.) About 1/12 of the words only occur once, and, contrary to popular belief, the word "gadzooks" never occurs!

Tables can be represented in C++ programs by STL maps. A map is a sequence of pairs, where pair is an STL type that simply binds two elements together:

For example, here is a concordance for a document containing the single phrase, "to be or not to be":

Here is one way we could build this concordance in C++:

Notice that we can use the array subscript operator to insert entries. In a way, a map is like an array indexed by an arbitrary type. In fact, if the index isn't a key in the table, a new pair is created with this key associated to the default or null value of the corresponding value type, and the new pair is inserted into the table. Since the "null" value for the integer type is 0, we can use this fact to create our concordance in a different way:

Here are useful template functions for writing pairs and maps:

For example,

prints:

Putting this together, here's how we can implement a concordance generator that reads a document from standard input and writes the concordance to standard output (we can use file redirection to read and write to files):

Unfortunately, searching a table is a little awkward using the map<> member functions. If m is a map and k is a key, then m.find(k) returns an iterator pointing to the first pair in m having key == k, otherwise m.end() is returned. We can make this job easier with the following template function that can be used to find the value associated with a particular key. The function returns false if the search fails:

Here's how we could learn the word count for a string in our concordance:

I/O is not built into the C++ language. Instead, it is provided in the standard library. To get the I/O facilities, you will need some of the following include directives in your program:

Input sources and output sinks— i.e., I/O devices, strings, and files—are represented in C++ programs by objects called streams. A stream can be thought of as a sequence of characters. An input stream is a sequence of characters coming from an input source. An output stream is a sequence of characters heading for an output sink. When a program needs input, it extracts characters from an input stream. When a program wants to perform output, it inserts characters into an output stream.

Output streams are instances of the class ostream, which is defined in <iostream>. There are several pre-defined output streams:

Initially, all three of these streams are associated with the monitor, but file redirection and pipes can re-associate cout with a file or the standard input stream of another program, while cerr and clog (which only differ in their buffering strategies) cannot be redirected.

The most basic service provided by instances of the ostream class inserts a single character into an output stream:

We can insert a whole string using the write() function:

Unfortunately, put() and write() only deal with characters. They do not perform translation from binary values to strings. The standard library provides translators that do this. All output translators are represented by the left shift operator. For example:

Because of overloading, this doesn't cause confusion. The C++ compiler can tell by the left operand, cout, that translation, not left shift is to be performed. The right operand tells it what type of translation is to be performed: int to string, double to string, etc.

Of course we can also use translators to write ordinary strings and characters:

Translators return their left operand as a value, thus several output operations can be chained together on a single line:

Because left shift is left-to-right associative, this is the same as:

Which is the same as:

We can even define our own translators. Assume rational numbers (i.e. fractions like 2/3, 1/8, and 7/5) are represented by two integers (the numerator and denominator) encapsulated in a struct:

Here are declarations of the rational numbers 3/8 and 2/1:

By defining our own variant of the left shift operator:

our rational numbers will be translated into strings and printed according to our desire:

Note: we must pass os by reference, because it is modified by having the numerator and denominator inserted into it. To allow chaining, we must also return os. Also note that os << rat.num and os << rat.den are calling the integer variant of left shift. They are not recursively calling the variant being defined.

Output File Streams

Writing to a file is easy. Simply declare an instance of the ofstream class. The constructor expects one input: the name of the file to open or create. The fstream class is derived from the ostream class, hence all of the operations discussed above, including left shift, can be used with file streams:

For example, the following code simply writes some strings and integers to a file called "data":

Of course the file created is simply a text file that can be inspected using an ordinary editor.

Output String Streams

Unfortunately, streams predated C++ strings; consequently, a large body of translators (i.e., insertion operators such as the one defined earlier for rationals) were developed that converted instances of programmer-defined types into strings that were immediately inserted into output streams. It would seem that these translators couldn't be used in situations where a value needed to be converted into a string that could be used for something other than output.

To remedy this situation, C++ allows strings to be output sinks. An output stream associated with a string is called an output string stream (ostringstream). Like output file streams, the class of output string streams is derived from ostream, hence inherits all of the functionality associated with that class:

To convert a value to a string, we insert the value into an output string stream using the insertion operator inherited from output streams. The str() member function can then be used to extract the string created inside the string stream. The following function formalizes this idea and makes a valuable addition to our utility library:

Here is a sample segment of code that uses this template:

Output is easy, but input is filled with pitfalls that await the unwary due to the gap between the actual and the expected types of incoming data.

Input streams are instances of the istream class. Analogous to output streams, the input file stream class (ifstream) and the input string stream class (istringstream) are derived from the istream class:

The standard input, mapped to the keyboard by default, is defined in <iostream>:

The basic service provided by an input stream extracts a single character:

Another version takes a character reference as a parameter:

Of course passing a constant to get() doesn't make sense:

Most streams buffer their characters, so it's possible to put an extracted character back into the input stream:

Or we can simply peek at the next character in the input stream without extracting it:

This is equivalent to:

Peek is useful when we need to know if the input stream contains a number before we attempt to extract a number:

It's also possible to extract C and C++ strings from an input stream:

The first version extracts up to 79 characters from cin and places them in buffer, followed by a null character. For both functions the extraction stops if the end of file or a newline character is encountered. If a newline character is encountered, it is discarded.

Translators are available for input streams, too. For example:

extracts characters up to the first character that cannot be construed as part of a double, translates these characters into the binary representation of a double, then assigns this double to x.

Of course if the extracted characters can't be construed as a double, for example, if the user types "nine" instead of "9", then the translator quietly fails. No error message is printed, no exception is thrown. Instead, a failure flag deep inside cin is set and subsequent read operations do nothing when executed.

A quick way to determine if the failure flag for a stream has been set is to compare the stream to 0, the null pointer. Since the extraction operator always returns its stream argument, we can extract characters and test for failure in a single operation:

As with the insertion operator, several extraction operations can be chained on the same line.

Right shift is right-to-left associative, so this is the same as:

Of course we can read strings and characters using the right shift operator:

Example: A Square Root Calculator

An important difference between the extraction operator and the get() and getline() is that by default, extraction terminates when the first white space is encountered. This can lead to obscure bugs. For example, assume a simple calculator perpetually prompts the user for a number, calculates and displays the square root of the number, then asks the user if he wants to quit:

Notice that response was initially read using cin.get(). This fails on most systems because characters are actually extracted from a buffer that contains the entire line that was typed. If the user entered the string "49\n" in response to the first prompt, then after "49" was extracted and converted to 49, the buffer still contains the newline character that terminated the numeric input. Because cin.get() doesn't skip white space, it reads this newline character as the response to the second prompt. The response is different from 'q', so the loop is reentered. The replacement:

works because the right shift operator skips white space, including the newline character. However, the user can't type "any" key to continue, as the second prompt suggests. Pressing the space bar, tab key, Return key, or Enter key— the usual "any key" candidates —moves the cursor, but doesn't cause any character to be extracted.

To solve this problem, we can flush the input buffer after the number is read. This is done with the synchronize function:

A much bigger problem is what happens if the user enters the string "forty-nine" instead of the string "49"? The extraction of x will fail because the string can't be converted into a number. At that point cin enters the fail state. No input operations can be performed while an input stream is in this state. On most systems this means the program spins wildly around the while loop, prompting the user, but never pausing to read an answer. (Try <Ctrl>c to interrupt.)

The failure flag of a stream can be cleared using the clear() function. Here's a template function that uses these features to safely read from cin:

In our calculator example we can now replace the lines:

by the single line:

Input File Streams

We can construct an input file stream from a file name:

If the file isn't found or if its permission level doesn't allow reading, then ifs will enter the fail state (i.e., it is set equal to 0):

We can use the null test again to determine when the end of the file is reached. This is more reliable than the eof() function, because that returns false even when only white space characters remain in the file:

For example, the following function computes the average of a file of numbers:

Of course if a non number is encountered in the file, even so much as a punctuation mark, the loop will exit and return the average of the numbers seen.

Input String Streams

Strings are character sources for input string streams. Here's the mate to the earlier template function that translated values to strings. This one translates strings into values. We must pass the value as a reference parameter so C++ can infer Value from calls to the function:

For example, here's how we could convert the string "123" into the integer 123:

Officially, a stream consists of three parts: a translator, a specification, and a stream buffer. The stream buffer encapsulates and manages an array of characters (i.e. the character buffer) waiting to be transferred to the program or to the output sink. The specification maintains the status and format state of the stream as well as a pointer to the stream buffer. Stream buffers are instances of the streambuf class, istream and ostream instances are translators, and specifications are instances of the ios class. Oddly, the designers of the stream library picked specialization as the relationship between translators and specifiers:

Programmers rarely need to directly access stream buffers, but if they do, they can use the rdbuf() function inherited from the ios base class to obtain a pointer to it. For example, one drawback of the input stream peek() function is that if there are no characters in the buffer, it blocks program execution until one shows up. This makes it unusable for situations where programmers want to poll multiple input streams. However, the streambuf class has a member function called in_avail() that returns the number of characters in the buffer without blocking. We can use this to create a useful stream-level version of the function:

A stream also inherits functions from its specification that allow programmers to determine its state. For example, if s is an input stream, then:

Although the state is an integer, it gets interpreted as a sequence of flags or bits indicating the status of s. We can access these bits directly with the predicates:

If s.good() is false, then subsequent extraction operations are no-ops. If s.bad() is true, forget it. The stream is broken. If s.fail() is true, then the stream can be repaired. Flush the remaining characters and set the state back to the good state using the setstate() function:

These functions are useful when we want to implement our own translators. Recall the Rational number class declared earlier:

When a user enters a rational number, we expect it to have the form a/b or a, where a and b are integers. Failure to meet any of these requirements results in setting the input stream state to fail, and returning immediately. For example, the inputs 3/x, 3\5, and x/5 should all result in a failed state. But what happens if the user types a single integer followed by some white space and a newline? Our policy will be to interpret this as a rational with denominator 1. We can use peek() to see if the next character is white space. Of course if the user enters "3 /5" this will be interpreted as 3/1 and the " /5" will be left in the buffer:

The line:

explicitly sets the fail bit if is. Of course if the user enters a non-integer numerator or denominator, the fail bit will already be set. However, if the user enters a valid numerator and denominator, but doesn't separate them with a slash, for example, if the user enters 3\5 instead of 3/5, then the fail bit won't be set automatically, so we must do it manually.

Output format is controlled by a sequence of flags in the specifier. Users can create their own sequence of format flags by combining predefined masks using bitwise disjunction:

The old flags are saved and the new ones installed by calling the flags() function:

In addition, the minimum width of the print field and the fill character can be set:

Now the statement:

produces the output:

The width reverts to 0 after each output operation.

Flags can be set or cleared individually using setf() and unsetf():

Some flags have three values instead of two:

Programmers can control the format and precision of floating point output. For example, assume the following declarations are made:

Using the default format settings, executing the lines:

produces the output:

If we change the floating point field in the format flag to scientific notation:

then the insertion statements will produce the output:

If we change the floating point field in the format flag to fixed point notation:

then the insertion statements will produce the output:

We can restore the general format by setting the floating point field to 0:

We can change the precision of the output using the precision() member function:

Notice that when we execute the insertion commands, only three digits are shown beyond the decimal point in pi:

Manipulators

Manipulators are functions that can be applied to output streams using the left shift operator syntax. For example, executing the statements:

produces the output:

Consult your online documentation or [STR] for a complete list of manipulators and to learn how to create your own manipulators.

C++ also provides an iostream class that multiply inherits from istream and ostream. The main purpose of iostream is to serve as a base class for fstream— the class of all file streams that can be opened for reading or writing —and stringstream— the class of all string streams that can be read from or written to:

For example, we initially declare an fstream without a file name:

The open() function is used to associate the fstream with a file and a flag (statically defined in ios) indicating if the file is to opened for input or output:

We can write data into a file stream the same way we would write data into and output stream:

If we now wish to reopen the same file for input, we first clear its error flag using the clear() function (this flag would have been set if we reached the end of the file), then close it using the close() function:

then call the open() function a second time, but using the input flag, ios::in:

We can now read data from the file the same way we would read from any input stream:

Readers should consult [STR] or on line documentation to gain a more comprehensive view of C++ I/O.

Assume an application is assembled from independently developed modules. How should errors detected by module M be handled? M has four choices:

The first option is just lazy programming. Ignoring an error will probably cause the program to enter an unstable state and eventually crash. When a program crashes, the operating system may print a cryptic message such as "core dump" or "segmentation violation," or the operating system may also enter an unstable state and eventually crash, requiring a reboot of the computer.

The second option is the one employed by the standard stream library. For example, when we attempt to extract a number from an input file stream, s, that doesn't contain a number, or when we attempt to associate s with a file that doesn't exist, then s enters a fail state, which we can detect by calling s.fail() or by comparing s to the null pointer. If we forget to occasionally check the state of s and repair it if it has failed:

then subsequent operations on s quietly turn into no-ops (i.e., operations that do nothing when they are executed). The program will speed passed subsequent read operations without pausing to extract data. Setting error flags places too much trust and too much burden on client modules.

The third option is ideal when we are debugging an application. When a problem occurs, the programmer wants to know what and where, which is what a good error message should tell him. Graceful termination means the program stops immediately and returns control to the operating system or debugger. We can achieve both of these goals by defining and calling a universal error() function:

The exit() function terminates the program and returns a termination code to the operating system or debugger. Termination code 0 traditionally indicates normal termination, while termination code 1 indicates abnormal termination.

After an application has been released to clients, option 3 is no longer acceptable. Clients will be annoyed if the program terminates unexpectedly and they lose all of their unsaved data. We must use option 4 in this situation. When an error is detected, the program must trace back to the point where the error was introduced. The state of the program at this point must be restored. If the error was caused by a bad user input, for example, then the program might prompt the user to reenter the data.

The problem with option 4 is that just because module M may detect an error, doesn't mean module M can repair the error. In fact, handling the error should be left up to client modules. For example, assume M is a package of mathematical functions called Math and UI is a user interface package that uses Math:

Suppose the UI package prompts the user for a number x, then some time later passes x to a log() function defined in Math and displays the result:

Suppose the user entered a negative number. Of course Math::log() will probably detect that its input is negative and therefore does not have a logarithm. But what should Math::log() do about the bad input? It's the responsibility of the UI package to interact with the user. If the log() function attempts to bypass the UI by reporting the error directly to the user and asking for another input, then it limits its reusability. For example, we wouldn't want to use such a function in a system with a graphical user interface. Also, result may be needed by subsequent calculations just as x may have been needed by previous calculations. Computing the log of a different number may not be relevant in this context.

Perhaps functions in the Math package could return some sort of error tokens to client packages when they detect bad inputs. This idea isn't bad, but it has several drawbacks. First, what should the error token be? For example, if a function returns a double, then we must either agree on a designated double to be used as the error token, which means this number can never be a normal return value. For example, many platforms provide a floating point representation of NaN (Not a Number), which can be referenced in C++ by the expression:

Of course we will have to do this for all possible return types. Alternatively, we could assign output values to a reference parameter and return a Boolean flag indicating if the operation was successful:

A bigger problem is that clients must check for the error token each time a function is called. If the return value is an error token, then the client must either handle the error or return an error token to its caller. For example, the following function uses our log() function to calculate the maximum data rate of a communication channel with bandwidth bw and signal-to-noise ration snr:

C++, Java, and other languages provide an error reporting mechanism that is similar to the idea of returning error tokens. When a function detects an error, it creates an error token called an exception, then uses the throw operator to "return" the exception to its caller:

A throw statement is similar to a return statement: it causes log() to terminate immediately. However, the exception returned by the throw statement is an arbitrary object that doesn't need to match the return type of the function. In our example the exception is an instance of an error token class we invented for representing and encapsulating all bad inputs:

Any other type of object could be thrown instead:

C++ even allows us to specify the types of exceptions a function might throw. For example, assume we define two exception classes for distinguishing between negative and zero inputs:

Here is how we can specify that our log() function might throw either exception:

Unlike Java, the compiler doesn't require us to declare which exceptions a function might throw. Also, the C++ compiler doesn't generate an error if a function throws a different type of exception than the ones specified. If this happens a system function named unexpected() is automatically called. The default implementation of unexpected() terminates the
program.

How does the calling function know if the called function throws an exception, and if so, what should it do? For example, let's re-implement the dataRate() function described earlier. Recall that this function uses our log() function to calculate the maximum data rate of a communication channel with bandwidth bw and signal-to-noise ration snr:

If snr <= -1, then log(1 + snr) will throw an exception. If this happens, then dataRate() implicitly throws the exception to its caller at the point where log() is called. In particular, dataRate() terminates immediately. The assignment and return statements are never executed.

C++ allows us to specify implicitly thrown exceptions, too:

In this way an exception explicitly thrown by log() is automatically propagated through the chain of calling functions. But how is the exception ultimately handled? If no function handles the exception, then the system-defined function named terminate() is automatically called. The default implementation of terminate() terminates the program.

If we think we can completely or partially handle some of the exceptions that might be thrown by certain functions, then we call these functions inside of a try block:

One or more catch blocks immediately follow a try block:

The thrown exception is passed to the catch block through the parameter specified in the parameter list following the reserved word "catch". The parameter type is used to control which handler is invoked when an exception is thrown. For example, if fun1() throws a ZeroInputException, then control is automatically transferred to the first line inside the second catch block.

Suppose our UI package calls dataRate(). Here is how we might handle the negative input exception it throws:

If we enter a signal to noise ratio of –2, then the following output is produced:

If we enter a signal to noise ratio of –1, then dataRate() implicitly throws a ZeroInputException. Because controlLoop() doesn't catch this type of exception, it too implicitly throws the exception.

If controlLoop() wanted to handle both exceptions, we could add an extra catch block for the ZeroInputException:

Alternatively, since ZeroInputException and NegInputException are both derived from BadInputException, we could handle both in a single catch block:

Unlike the flag-setting stream library, the standard template library throws exceptions when things go wrong. The pre-defined exception classes are defined in the <stdexcept> header file:

The base class for all STL exceptions is exception class.

The what() member function normally returns an error message encapsulated by the exception.

The two principle derived classes are logic_error and runtime_error, although there are a number of other exception classes derived from exception:

The distinction between these two classes is a little shaky. Presumably, a logic error occurs when a bad thing happens to a bad program. In other words, a logic error is an error in the program, such as passing an invalid argument, using an index that's out of range, attempting to access elements in an empty container, etc. A runtime error occurs when a bad thing happens to a good program. In other words, a runtime error is an error caused by the program's environment, not the program itself, such as an overflow or underflow error. More commonly, runtime errors are thrown when information specified by the user, such as the name of a file to be opened or the index of an array to be accessed, is invalid.

For example, here is how we might deal with the problem of attempting to open a missing or protected file:

Here is a list of the current exception classes defined in the standard C++ library. Indentation indicated derivation depth:

We can improve the error() function mentioned earlier by controlling its behavior with a global flag indicating if we are in debug or release mode:

In debug mode, the error() function prints an error message and terminates the program. In release mode a runtime error is thrown:

One problem with this approach is that it prevents us from being more specific about the type of exception we are throwing, hence we can't steer our exception to a particular catch block.

Assume an application will consist of a provider module called Engine and a client module called Car:

Of course the implementer of the Engine module may have no knowledge of the Car client module. Indeed, there may be other client modules.

When problems occur in the Engine module, exceptions are thrown. It's up to the client module to decide how to handle these exceptions. The Engine module can help its clients by providing a carefully designed hierarchy of exceptions. This allows the client to decide the granularity of exception handling. Fore example, should an exception indicating that the oil is low be handled by the same function that handles exceptions indicating that the gas is low? Remember, making this decision is the client's privilege.

The Engine subsystem contains several types of engines together with a hierarchy of exceptions representing typical engine problems:

We can implement the Engine subsystem as a C++ namespace:

Instances of the base class of all engine errors encapsulate error messages:

We could have derived EngineErr from one of the predefined exception classes such as exception or runtime_error:

This would give clients the option of treating all exceptions the same way.

The LowOil, LowGas, and TooFast exceptions encapsulate the current oil, gas, or engine speed, respectively. For example:

State errors occur when we try to drive a car isn't running or change the oil in a car that is running:

For example, here is the exception thrown when we attempt to change oil in a running car:

A typical engine is the V8:

The implementation of run() first passes through a gauntlet of throw statements:

Here is the implementation of getGas():

The Car subsystem depends on the Engine subsystem:

We can represent the Car subsystem as a C++ namespace:

Notice that Ford member functions declare the exceptions they implicitly throw. Naturally, the exceptions they handle aren't specified in the exception list. For example, start() catches the Running exception thrown by Engine::start(), so it only throws LowGas and LowOil:

The control panel (i.e., dashboard) for an associated car redefines the default terminate() and unexpected() functions:

Here are the new versions:

The control loop catches all Engine exceptions:

Notice that the last catch block will catch all engine exceptions not specified above.

The test driver uses a catch-all block to catch any type of exception (system defined or programmer defined):

One of the original design goals of C++ was to eliminate the bug-infested gap between object creation and object initialization. When a C++ object is created, a user-defined or system-defined constructor is automatically called to initialize the object's member variables.

An initializer list is a list of pre-initializations— member variable initializations that occur in the imperceptibly brief gap between object creation and the execution of the first line of the called constructor. Syntactically, the list is announced by a colon and is sandwiched between the header of a constructor and its body:

Why not initialize all member variables inside the constructor's body? Because some member variables are in "hard to reach" places. For example, inherited member variables may have been declared private in the base class, and nested member variables— i.e., member variables of member objects —may have been declared private in the associated class.

Assume an Employee class has a private member variable called name of type string, which is initialized by Employee constructors. Assume a Manager class and a Secretary class are derived from the Employee class:

Secretaries have a private integer member variable called wpm, which represents typing speed in words per minute. Managers have a private Boolean member variable called canUseJet, which indicates if recreational use of the company jet is allowed on weekends. Each manager object also has a private member variable called sec of type Secretary, which represents the manager's personal secretary:

In addition to the explicitly declared canUseJet and sec variables, a manager object also encapsulates the inherited name variable as well as the nested sec.name and sec.wpm. For example, the declaration:

might create an object in memory that looks like this:

But how can a Manager constructor initialize these implicit member variables? If we leave them uninitialized, then the Employee and Secretary default constructors— if they exist —will be automatically called to perform the pre-initializations, but this doesn't help us.

We can't simply initialize them in the constructor's body:

The Manager constructor could create an anonymous temporary secretary object, then assign it to sec:

But this can be inefficient if the default Secretary constructor, which is still automatically called to pre-initialize the sec variable, consumes a lot of time or memory, and of course we still have the problem of initializing the inherited name variable. Calling the Employee constructor inside the body of the Manager constructor only creates a temporary anonymous employee object with a name member variable that is unrelated to the inherited name member variable.

The solution to our problem is to use the initializer list to specify any non-default constructors that should be called to pre-initialize inherited and nested member variables:

Notice that the Employee base class constructor is explicitly called, while the Secretary constructor is implicitly called by specifying the arguments after the sec variable.

In addition to inherited and nested private member variables, constant member variables also present an initialization problem. Constants are read-only variables. It's an error for a constant to appear on the left side of an assignment statement:

So how do we initialize a constant? This must be done in its declaration:

But then how do we initialize constant member variables like critical, the constant member of our nuclear reactor class from chapter 2?

Initializing critical in the constructor's body will be regarded as an illegal assignment statement by the compiler:

Fortunately, we can also use the initializer list to pre-initialize constant members:

Recall that the initial value of a simple variable can be specified using C syntax:

or C++ syntax:

Initializer lists always use the latter form.

What is the advantage of having constant members? Why not simply define critical to be a global constant or a member of an anonymous, nested enumeration:

Well for one thing, members of enumerations must be integers, not doubles. But more importantly, declaring critical to be a constant member means different reactors can have different critical temperatures.

References are essentially constant pointers, so we run into the same initialization problems we faced with constants. For example, assume reactors send notifications of temperature changes to a monitor that is represented by a reference to an output stream:

Like constants, references must be initialized in the initializer list:

It turns out that all member variables can be initialized in an initializer list, leaving the constructor body empty:

A declaration creates a binding between a name and a bindable (e.g., a type, variable, or function). For example, the declaration:

creates a binding between the name x and an integer variable. (See Programming Note A2.2) Of course a name may be bound to multiple bindables, and a bindable may be bound to multiple names.

The visibility of a binding is the lexical region of the program where the binding is valid. A binding has global visibility if it is visible throughout the entire program, otherwise we say the binding has local visibility.

The extent of a binding (also called the lifetime of a binding) is the period of time that the binding exists. A binding has global extent if it exists from the moment of its declaration until the program terminates, otherwise we say the binding has local extent.

Generally speaking, global visibility implies global extent and local visibility implies local extent, although in some cases a binding with local visibility may have global extent. (Why would global visibility with local extent would be a recipe for disaster?)

Unfortunately, there is no simple or elegant mapping between these concepts and C/C++ terminology. C++ programmers speak of the scope of a name, rather than the visibility of a binding. Even the phrase "scope of a name" is inaccurate. What is really meant is the scope of a declaration, which simply refers to the file, namespace, class, or block in which the declaration occurs.

The scope of a declaration is loosely related to the visibility of the binding it creates. For example, a declaration with block scope creates a binding that is only visible from the point of declaration to the end of the block. A declaration with file scope creates a binding that is visible from the point of declaration to the end of the file, unless the binding is explicitly imported to another file. For example, placing the declaration:

in a source file means the binding between the name pi and the constant 3.1416 is visible from the point of declaration to the end of the file. However, we can refer to this binding in other files by including the pure declaration:

Recall that when a C or C++ program is loaded in memory, it is allocated four segments of memory:

In addition, program data can also be stored in the processor's registers. The storage class of a variable refers to the memory segment where the variable is located: register, heap, stack, or static. (C/C++ uses the term automatic to refer to stack variables.)

C++ programmers speak of the storage class of a variable rather than the extent of a binding. There is a loose relationship. For example, bindings to static variables have global extents, while bindings to automatic variables have local extents. (Heap variables come into existence when the new() operator is called and disappear when the delete() operator is called.)

The relationship between the storage class of a variable and the scope of variable's declaration is tricky. Normally, a variable declaration with file scope produces a binding to a static variable, while a variable declaration with block scope produces a binding to an automatic variable. However, we can override this by specifying the storage class in the declaration.

For example, suppose we want to define a function that returns the number of times it has been called. The following definition fails because we keep the call count in a variable created by a block-scope declaration which is created (and initialized to 0) each time the function is called, and is destroyed each time the function terminates:

We can remedy the situation by specifying the call count to be static:

Curiously, placing static in front of a file scope declaration limits the scope of the binding it creates to the file in which it is declared. I.e., it cannot be exported into other files.

Scope, visibility, extent, and storage class become very confusing when we think about member variables and functions. For example, consider the following class declaration:

All of the member declarations have class scope according to C++ terminology. However, this doesn't tell us much about visibility, extent, or storage class. The declaration of balance, for example, doesn't create a variable. No variable is created until we create some instances of the Account class:

At this point three variables have been created: a.balance, b.balance, and c.balance. The extent and storage class of these variables will be the same as the extend and storage class of a, b, and c, respectively. The visibility of the bindings between these qualified names and the corresponding variables is restricted to member functions of the Account class and all classes derived from the Account class. This is because balance was declared protected.

The unqualified name balance, is bound to all three variables, but the visibility of each binding is restricted to member functions of the Account class and all classes derived from the Account class. In this case the restricted visibility has nothing to do with the fact that balance is a protected member variable, the visibility of the binding remains unchanged even if balance is public! (In truth, the compiler replaces all unqualified references to balance by the qualified reference this->balance.)

Placing the static specifier in front of a member variable has two consequences. First, static member variables are allocated in the static memory segment, as expected. Second, static member variables are not encapsulated in objects! A static member variable is unique, and it has global extent: it comes into existence before main() begins execution, and disappears when main() terminates.

For example, suppose we want to keep track of the number of account objects that exist. It wouldn't make sense to store the count in an ordinary member variable. In this case every account object would encapsulate a count variable. But this leads to a chicken-versus-egg problem: the count variable only exists if account objects exist to encapsulate it. How could it ever be 0? Also, each time a new account is created or destroyed, we would have to update each remaining account's count variable. We could store the count in a global variable (i.e. a variable created by a file-scope declaration):

Of course file scope variables have global visibility, so there is a possibility of corruption. The best strategy is to use a private static member variable:

Notice that Account constructors increment count while the Account destructor decrements count. (Why was it necessary to define a new copy constructor?)

The chicken-versus-egg problem is solved because the extent of count is global, it isn't tied to the extent of any particular account object. The corruption problem is solved, too. The visibility of count is restricted to Account member functions because it is private.

How will clients access count? Outside of the class scope the variable goes by its qualified name: Account::count, but this doesn't help, because it is still a priavte variable. We could provide a public member function for this purpose:

But this leads back to the chicken-versus-egg problem. An account object must exists before we can call its getCount() member function.

Fortunately, member functions can also be declared static:

Unlike ordinary member functions, static member functions don't have implicit parameters. This means they can be called even if no instance of the class exist. For example, here's how a client might display count:

One last problem: how will Account::count get initialized to 0? We can't initialize it in an Account() constructor, because constructors are only called when objects are created and they are called each time an object is created. In fact, the declaration of count is only a pure declaration, it does not bind Account::count to any particular variable, it only says that it will be bound to a variable. We still need the definition:

This definition would normally be a file-scope declaration in a source file such as account.cpp.

Sometimes strict type checking can limit the flexibility of an algorithm. For example, it would be a real headache if the cos() function refused to accept integer arguments:

Fortunately, the C++ compiler recognizes many of these situations and automatically converts the given value to an equivalent value of the expected type.

In some situations this might involve actually transforming the internal representation of the value. This is called coercion. For example, the C++ compiler automatically translates cos(0) to cos(0.0). Of course the internal representation of 0 is quite different from the internal representation of 0.0.

In other situations the internal representation doesn't need to change, it only needs to be temporarily retyped. For example, assume the following inheritance hierarchy has been defined:

Assume we define a pointer to an executive object:

We can freely use this pointer in contexts where pointers to employees are expected:

In this case the compiler simply retypes the pointer to the expected type. The actual value of the pointer doesn't need to change because a pointer to an Executive is— technically and logically —a pointer to an Employee.

C/C++ uses the term casting to refer to both coercion and retyping. Retyping an Executive pointer to an Employee pointer is called up casting because the target type is a base class of the original type. Up casts are performed automatically by the compiler, as required. A cast that is performed automatically is called an implicit cast.

By contrast, a down cast replaces the original type with a more specialized derived class. Of course this only makes sense if the pointer actually points to an instance of the more specialized class. For example, assume we need a single pointer that can be used to point at all types of employees. Only an Employee pointer allows this flexibility:

At one point in our program we point our emp pointer at an Executive object:

Assigning an Executive pointer to an Employee pointer is an up cast, so the C++ compiler automatically performs the necessary retyping operation. Now suppose we want to find out the bonus of this employee using the Executive::getBonus() member function:

This generates a compile-time error because the C++ compiler has no way of knowing that emp actually points to an Executive object, and of course there is no Employee::getBonus() member function.

Of course we know that emp points to an Executive, so we can tell the compiler to perform the cast using the static_cast() operator:

We can also use the traditional C syntax to perform static casts:

If a type has a simple name, for example if we introduce ExecPointer as a synonym for pointers to Executives:

then we can also use "function call" syntax to perform static casts:

In contrast to implicit casts, casts performed by the programmer— regardless of the syntax used —are called explicit casts.

We have to be careful, though. If emp doesn't really point at an Employee, if emp points at a Programmer instead:

then our static cast forces the compiler to point an Executive pointer at a Programmer object, and calling exec->getBonus() causes the program to crash or, worse yet, produces the incorrect answer.

We can guard against this type of error by using the dynamic cast operator, which uses runtime type information (RTTI, see chapter 6) to determine if the object is actually an instance of the target type. If not, then the null pointer, 0, is returned:

Note: dynamic casting requires the base class to be virtual (i.e., at least one member function must be virtual, the destructor for example). Also, some compilers may require special RTTI options to be designated.

When we introduce multiple inheritance into our hierarchy, then we allow the possibility of cross casts. For example, assume a company's chief executive officer (CEO) must be an employee and a stock holder:

Assume an Employee pointer actually points at a CEO object:

At some point in the program we may want to know how many shares of stock gates owns, but Employee is neither a base class nor a derived class of StockHolder, so neither an up cast nor a downcast will work in this situation, and consequently the static cast:

causes a compile-time error. Retyping gates as a StockHolder is called a cross cast because the target type is a peer of the original type. Cross casts must be performed dynamically:

C++ also offers the reinterpret_cast() and const_cast() operators. The const_cast() operator is used to retype a variable of type const T* to a variable of type T*. For example:

Of course review(smith) only changes smith.bonus if smith was not declared as a constant.

The reinterpret_cast() operator is the elephant gun of casting operators. Using it, we can force the compiler to perform static casts it would otherwise disallow. For example, the compiler would normally disallow a static cast from a pointer to an integer::

But if we are real sure we know better than the compiler, then we can force the retyping operation:

We can declare a coercion from an existing type, T, to a programmer-defined class, C, by simply declaring a constructor for C that expects a single parameter of type T.

We can declare coercion from C to T by defining a member function for C that overloads the T() casting operator (i.e., the operator called by T(exp)):

The C++ compiler will automatically call the appropriate coercion when it sees an instance of C appearing in a context where an instance of T is expected, and vice-versa.

For example, suppose we define a rational number class with two integer member variables representing numerator and denominator:

Every integer, n, can be interpreted as the rational n/1, therefore we would like to be able to use integers in contexts where rational numbers are expected. For example, we would like to be able to assign an integer to a Rational variable:

In this case the compiler will automatically search for a Rational constructor that expects a single integer parameter. If it finds one, it will translate the assignment as:

In our example, the compiler will use the constructor above with the default second argument:

Every rational number can be approximated by a floating point number. For example, 7/6 could be approximated by 1.166660. In general, the rational n/m is approximated by the floating point result of dividing n by m. Therefore, we would like to be able to use rationals in contexts where floating point numbers are expected. For example, we may want to assign a rational number to a variable of type double:

Defining a Rational constructor that expects a single parameter of type double doesn't help, because it would coerce doubles to rationals, and we need to go the other way; we need to coerce rationals to doubles. This is easy to do if we realize that static casts such as:

are actually calls to an operator that can be overloaded. The syntax is a little weird, though. The official name of the operator is "operator double()" (i.e., a blank space is part of the name!). Also, this operator must always return a double, so as with constructors, C++ doesn't allow programmers to specify the return type. (Otherwise the compiler would need to decide how to respond if the programmer specified the wrong return type.) Here is our definition of the double() operator for rationals:

The compiler will automatically translate the assignment given above to:

We occasionally contrast C++ with LISP, a flexible, interpreted, expression-oriented language developed by John McCarthy in 1960. LISP is commonly used to implement artificial intelligence applications such as expert systems. Our examples use the Scheme dialect of LISP. Technically speaking, Scheme isn't a dialect of LISP, because it doesn't conform to the Common LISP standard.

LISP syntax is strange. There are no infix operators, only prefix operators, and a function's name or operator symbol is placed inside its argument list! For example, the expression
30 + 12 is written as:

the expression 6 * 5 + 4 * 3 is written as:

and the expression sin(atan(x, y)) is written as:

Unlike C++ functions, the body of a LISP function consists of a single return statement. This is because although assignment statements are available in LISP, their use is de emphasized, and so there's not much else to do in the body of a LISP function other than to return the value produced by a parameterized expression. Furthermore, because return statements are the only statements in the body, there's no need for an explicit return command as in C++. For example, the C++ function:

Would be defined in LISP by:

See [PEA] for more details on the Scheme dialect of LISP.

All Java classes implicitly specialize Java's Object class. This makes it easy to create heterogeneous containers such as stacks, because we can generically refer to the items stored in the stack as objects:

Of course clients must down cast items popped off the stack:

In addition, we can put useful operations in the Object base class that we want all objects to inherit. For example, Java's Object class includes the methods clone(), getClass(), and toString(). Java's Object base class is comparable to MFC's CObject base class.

Unlike C++, each member of a Java class must be declared public, protected, or private. Unfortunately, specifying the access of every single member gets to be quite tiring. If we forget to specify the access of a member, then the default is package scope, which means the member is visible to member functions in other classes defined in the same package.

By default, all Java member functions are virtual functions. In other words, selecting the variant of an overloaded member function is done dynamically. If we don't want a function to be virtual, then we must explicitly declare it to be non-virtual by writing the reserved word "final" in front of the function's declaration:

Java variables don't hold objects, instead, they hold references to heap-based objects. (A reference is a pointer that automatically dereferences itself.) For example, the declaration:

does not create any object, x is merely a variable that can hold a reference to an object. Of course we can assign a reference to any instance of a class that extends the Animal class, and the up cast will be performed automatically:

The analogous situation in C++ would be: