We only need to change the definition of Storable in the following implementation of stack to transform it from an integer stack to a stack employee records:

What do we do if we want to stack integers and employees in the same program? Storable can't have two definitions. We'll have to duplicate the stack code:

A template is a pattern for creating classes (and a class is a pattern for creating objects) or functions. A template looks like an ordinary class or function declaration, but it may contain type (or value) parameters. A type parameter, X, is identified by writing the line:

or

The compiler creates instances of a template (i.e., classes or functions) by replacing X by a real type or class (or value).

By defining Storable to be a type parameter, we can get C++ to create stack types for us:

Programmers create instances of a template by specifying a type argument in <> brackets:

Note the complicated syntax used to implement the push function:

the first line is necessary because push is a template function. Member functions can be templates just as global functions can. In this case, the push function makes several references to Storable, so the compiler needs to be told that Storable is a type parameter. One unavoidable reference to storable occurs in push's qualifier. Push is not a member function of the Stack class. Stack isn't a class, it's a template. Rather push is a member function of the Stack<Storable> class.

Also note that the implementation and declaration of the stack template was entirely contained in stack.h, which was then included in main.cpp. We can't separate the declaration of a template from its implementation. Remember, a template is a recipe used by the compiler to create class declarations. As such the entire recipe, declaration and implementation, must be included in each file where template instances are declared.

We can now better understand the vector template provided by the standard C++ library. In fact, the standard library provides several container types defined as templates: list, deque, stack, queue, map, etc. Collectively, these are known as the standard template library, STL.

A function should validate its inputs, but what should it do if it discovers one of its inputs isn't valid? There are four alternatives:

In the last option, how do we trace back to where the invalid input first appeared? One idea is to return an error token to the calling function when an invalid input is detected. The calling function could either attempt to handle the problem, or it could return the error token to its caller. Thus, the error token could be propagated all the way through the control stack until it reaches a function that is in a position to handle the error.

There are several problems with this strategy. First, if a function returns a double, for example, which value should be designated as the error token? Second, the calling function needs to explicitly check the return value to see if it's an error token.

C++ automates this process with its catch and throw mechanism. Instead of one return channel between called and caller functions, there are two, one for normal return values, the other for special error tokens called exceptions. An exception e is returned to the caller not with the return statement, but with the throw statement: throw e.

Further, the caller need not check for error tokens. If a called function throws an exception, then the caller function implicitly throws the exception.

For example, let's define a class of exceptions we will throw whenever invalid inputs are detected. Our exception objects will encapsulate error messages:

Here's a (useless) square function that only squares unsigned numbers. It explicitly throws an input exception if it's called with a negative input. For diagnostic purposes it prints entry and exit messages. Executing throw(exp) is like executing a return statement, the function immediately terminates (thus the exit message won't be printed).

The cube function calls the square function. If square(x) throws an exception, then cube implicitly throws an exception at the same point, thus terminating and not printing the exit message.

Alternatively, a function can handle the exception thrown by a called function rather than propagate the exception to its caller. This is done by calling the dangerous function inside a try-catch block:

If a statement inside the try block throws a SyntaxException or an InputException, control is immediately transferred to the first line of the appropriate catch block. Further, the thrown exception is bound to the parameter e, so it is available to the handler code. Unless the handler code changes the flow of control, control will fall through to the next statement following the try-catch block.

For example, displayCube() catches the exception implicitly thrown by cube:

Here's a sample main():

At the point square is called the control stack looks like this:

Here's the output of main(). Notice that the second time displayCube() is called, the exit statements for cube and square are not printed:

Unlike the stream library functions which set flags, he newer C++ standard library functions throw exceptions when errors are detected. All exceptions thrown are instances of classes derived from:

The principle derived classes which can be found in <stdexcept>:

Runtime errors are errors that are only detectable when the program executes, while logic errors are detectable before the program executes. In other words, runtime errors are thrown when bad things happen to good programs, while logic errors are thrown when bad things happen to bad programs.

We can (and should) create our own exception classes as derived classes of these classes. For example, recall that our error() function throws a runtime_error when DEBUG_MODE is false:

Let's divide the stack calculator example into a reusable, interpreter-specific framework, and a stack-specific customization. To keep things simple, the implementation assumes commands, like Results, are no more that dumb strings, so a parser won't be necessary:

Any context must implement an execute() function:

The interpreter framework provides a control loop and maintains a pointer to the context:

The interpreter's control loop just passes the user's command to the context's execute function. It is assumed that the context will throw a runtime error exception if the command is problematic:

Let's use our framework to build the stack calculator. A stack context is a concrete derived class of Context. Taking advantage of multiple inheritance, it is also derived from Stack<Number>. Finally, to add an extra measure of reusability, Number is a template parameter.

The execute() function throws a runtime exception if the command isn't recognized:

The stack template follows the implementation given earlier, except runtime exceptions are thrown if stack overflow or underflow occurs:

Here's main:

Here's a sample output of the stack calculator. Notice that errors like unrecognized commands or stack under/over flow don't break the application:

Redo the turtle graphics application as a customization of the interpreter framework.

Recall that message passing is an alternative way for objects to communicate. The key to a message passing architecture is a dispatcher. A dispatcher maintains a queue of messages and a list of pointers to potential targets (use a vector). The message loop perpetually removes messages from its queue, locates the target, then sends the message to the target. The send() function permits targets to send messages to each other:

Implement and test a framework for building message passing applications.