Using a Base Class Pointer

In the previous chapter, you saw how an object of a derived class type contains a subobject of the base class type. In other words, you can regard every derived class object as a base class object. Because of this, you can always use a pointer to a base class to store the address of a derived class object; in fact, you can use a pointer to any direct or indirect base class to store the address of a derived class object. Figure 14-1 shows how the Carton class is derived from the Box base class by single inheritance, and the CerealPack class is derived by multiple inheritances from the Carton and Contents base classes. It illustrates how pointers to base classes can be used to store addresses of derived class objects.

The reverse is not true. For instance, you can’t use a pointer of type Carton* to store the address of an object of type Box. This is logical because a pointer type incorporates the type of object to which it can point. A derived class object is a specialization of its base—it is a base class object—so using a pointer to the base to store its address is reasonable. However, a base class object is definitely not a derived class object, so a pointer to a derived class type cannot point to it. A derived class always contains a complete subobject of each of its bases, but each base class represents only part of a derived class object.

We’ll look at a specific example. Suppose you derive two classes from the Box class to represent different kinds of containers, Carton and ToughPack. Suppose further that the volume of each of these derived types is calculated differently. For a Carton made of cardboard, you might just reduce the volume slightly to take the thickness of the material into account. For a ToughPack object, you might have to reduce the usable volume by a considerable amount to allow for protective packaging. The Carton class definition could be of the following form:

The ToughPack class could have a similar definition:

Given these class definitions (the function definitions follow later), you can declare and initialize a pointer as follows:

The pointer pBox, of type pointer to Box, has been initialized with the address of carton. This is possible because Carton is derived from Box and therefore contains a subobject of type Box. You could use the same pointer to store the address of a ToughPack object because the ToughPack class is also derived from Box:

The pBox pointer can contain the address of any object of any class that has Box as a base. The type of the pointer, Box*, is called its static type. Because pBox is a pointer to a base class, it also has a dynamic type, which varies according to the type of object to which it points. When pBox is pointing to a Carton object, its dynamic type is a pointer to Carton. When pBox is pointing to a ToughPack object, its dynamic type is a pointer to ToughPack. When pBox points to an object of type Box, its dynamic type is the same as its static type. The magic of polymorphism springs from this. Under conditions that we’ll explain shortly, you can use the pBox pointer to call a function that’s defined both in the base class and in each derived class and have the function that is actually called selected at runtime on the basis of the dynamic type of pBox. Consider these statements:

If pBox contains the address of a Carton object, then this statement calls volume() for the Carton object. If it points to a ToughPack object, then this statement calls volume() for ToughPack. This works for any classes derived from Box, provided of course the aforementioned conditions are met. If they are, the expression pBox->volume() can result in different behavior depending on what pBox is pointing to. Perhaps more importantly, the behavior that is appropriate to the object pointed to by pBox is selected automatically at runtime.

Polymorphism is a powerful mechanism. Situations arise frequently in which the specific type of an object cannot be determined in advance—not at design time or at compile time. Situations, in other words, in which the type can be determined only at runtime. This can be handled easily using polymorphism. Polymorphism is commonly used with interactive applications, where the type of input is up to the whim of the user. For instance, a graphics application that allows different shapes to be drawn—circles, lines, curves, and so on—may define a derived class for each shape type, and these classes all have a common base class called Shape. A program can store the address of an object the user creates in a pointer, pShape, of type Shape* and draw the shape with a statement such as pShape->draw(). This will call the draw() function for the shape that is pointed to, so this one expression can draw any kind of shape. Let’s take a more in-depth look at how inherited functions behave.

Calling Inherited Functions

Before we get to the specifics of polymorphism, we need to explain the behavior of inherited member functions a bit further. To help with this, we’ll revise the Box class to include a function that calculates the volume of a Box object, and another function that displays the resulting volume. The new version of the class definition in Box.h and Box.cpp will be as follows:

We can display the usable volume of a Box object by calling the showVolume() function for the object. The member variables are specified as protected, so they can be accessed by the member functions of any derived class.

We’ll also define the ToughPack class with Box as a base. A ToughPack object incorporates packing material to protect its contents, so its capacity is only 85 percent of a basic Box object. Therefore, a different volume() function is needed in the derived class to account for this:

Conceivably, you could have additional members in this derived class, but for the moment, we’ll keep it simple, concentrating on how the inherited functions work. The derived class constructor just calls the base class constructor in its member initializer list to set the member variable values. You don’t need any statements in the body of the derived class constructor. You also have a new version of the volume() function to replace the version from the base class. The idea here is that you can get the inherited function showVolume() to call the derived class version of volume() when you call it for an object of the ToughPack class. Let’s see whether it works:

When we run the program, we get this rather disappointing output:

The derived class object is supposed to have a smaller capacity than the base class object, so the program is obviously not working as intended. Let’s try to establish what’s going wrong. The second call to showVolume() in main() is for an object of the derived class, ToughPack, but evidently this is not being taken into account. The volume of a ToughPack object should be 85 percent of that of a basic Box object with the same dimensions.

The trouble is that when the volume() function is called by the showVolume() function, the compiler sets it once and for all as the version of volume() defined in the base class. No matter how you call showVolume(), it will never call the ToughPack version of the volume() function. When function calls are fixed in this way before the program is executed, it is called static resolution of the function call, or static binding. The term early binding is also commonly used. In this example, a particular volume() function is bound to the call from the function showVolume() when the program is compiled and linked. Every time showVolume() is called, it uses the base class volume() function that’s bound to it.

What if you call the volume() function for the ToughPack object directly? As a further experiment, let’s add statements in main() to call the volume() function of a ToughPack object directly and also through a pointer to the base class:

Place these statements at the end of main(). Now when you run the program, you’ll get this output:

This is quite informative. You can see that a call to volume() for the derived class object, hardcase, calls the derived class volume() function, which is what you want. The call through the base class pointer pBox, however, is resolved to the base class version of volume(), even though pBox contains the address of hardcase. In other words, both calls are resolved statically. The compiler implements these calls as follows:

A static function call through a pointer is determined solely by the pointer type and not by the object to which it points. In other words, it is determined by the static type rather than the dynamic type. The pointer pBox has a static type pointer to Box, so any static call using pBox can only call a member function of Box.

What we want is for the volume() function that is to be called in any given instance to be resolved when the program executes. So, if showVolume() is called for a derived class object, we want the derived class volume() function to be called, not the base class version. When the volume() function is called through a base class pointer, we want the volume() function that is appropriate to the object pointed to in order to be called. This sort of operation is referred to as dynamic binding or late binding. To make this work, we have to tell the compiler that the volume() function in Box and any overrides in the classes derived from Box are special, and calls to them are to be resolved dynamically. We can obtain this effect by specifying that volume() in the base class is a virtual function, which will result in a virtual function call for volume().

Virtual Functions

When you specify a function as virtual in a base class, you indicate to the compiler that you want dynamic binding for function calls in any class that’s derived from this base class. A virtual function is declared in a base class by using the keyword virtual, as shown in Figure 14-2. Describing a class as polymorphic means that it is a derived class that contains at least one virtual function.

A function that you specify as virtual in a base class will be virtual in all classes that are directly or indirectly derived from the base. This is the case whether or not you specify the function as virtual in a derived class. To obtain polymorphic behavior, each derived class may implement its own version of the virtual function (although it’s not obliged to—we’ll look into that later). You make virtual function calls using a variable whose type is a pointer or a reference to a base class object. Figure 14-2 illustrates how a call to a virtual function through a pointer is resolved dynamically. The pointer to the base class type is used to store the address of an object with a type corresponding to one of the derived classes. It could point to an object of any of the three derived classes shown or, of course, to a base class object. The type of the object to which the pointer points when the call executes determines which volume() function is called.

Note that a call to a virtual function using an object is always resolved statically. You only get dynamic resolution of calls to virtual functions through a pointer or a reference. Storing an object of a derived class type in a variable of a base type will result in the derived class object being sliced, so it has no derived class characteristics. With that said, let’s give virtual functions a whirl. To make the previous example work as it should, a very small change to the Box class is required. We just need to add the virtual keyword to the definition of the volume() function:

To make it more interesting, let’s implement the volume() function in a new class called Carton a little differently. Here is the class definition:

The volume() function for a Carton object assumes the thickness of the material is 0.25, so 0.5 is subtracted from each dimension to account for the sides of the carton. If a Carton object has been created with any of its dimensions less than 0.5 for some reason, then this will result in a negative value for the volume, so in such a case, the carton’s volume will be set to zero.

We’ll also use the ToughPack class from Ex14_01. Here’s the code for the source file containing main():

The output that is produced should be as follows:

Notice that we have not added the virtual keyword to the volume() functions of either the Carton or ToughPack class. The virtual keyword applied to the function volume() in the base class is sufficient to determine that all definitions of the function in derived classes will also be virtual. You can optionally use the virtual keyword for your derived class functions as well, as illustrated in Figure 14-2. Whether or not you do is a matter of personal preference. We'll return to this choice later in this chapter.

The program is now clearly doing what we wanted. The call to showVolume() for the box object calls the base class version of volume() because box is of type Box. The next call to showVolume() is for the ToughPack object hardcase. It calls the showVolume() function inherited from the Box class, but the call to volume() in showVolume() is resolved to the version defined in the ToughPack class because volume() is a virtual function. Therefore, you get the volume calculated appropriately for a ToughPack object. The third call of showVolume() for the carton object calls the Carton class version of volume(), so you get the correct result for that too.

Next, you use the pointer pBox to call the volume() function directly and also indirectly through the nonvirtual showVolume() function. The pointer first contains the address of the Box object box and then the addresses of the two derived class objects in turn. The resulting output for each object shows that the appropriate version of the volume() function is selected automatically in each case, so you have a clear demonstration of polymorphism in action.

Virtual Functions and Class Hierarchies

If you want your function to be treated as virtual when it is called using a base class pointer, then you must declare it as virtual in the base class. You can have as many virtual functions as you want in a base class, but not all virtual functions need to be declared within the most basic base class in a hierarchy. This is illustrated in Figure 14-3.

When you specify a function as virtual in a class, the function is virtual in all classes derived directly or indirectly from that class. All of the classes derived from the Box class in Figure 14-3 inherit the virtual nature of the volume() function, even if they do not repeat the virtual keyword. You can call volume() for objects of any of these class types through a pointer of type Box* because the pointer can contain the address of an object of any class in the hierarchy.

The Crate class doesn’t define volume(), so the version inherited from Carton would be called for Crate objects. It is inherited as a virtual function and therefore can be called polymorphically.

A pointer pCarton, of type Carton*, could also be used to call volume(), but only for objects of the Carton class and the two classes that have Carton as a base: Crate and Packet.

The Carton class and the classes derived from it also contain the virtual function doThat() . This function can also be called polymorphically using a pointer of type Carton*. Of course, you cannot call doThat() for these classes using a pointer of type Box* because the Box class doesn’t define the function doThat().

Similarly, the virtual function doThis() could be called for objects of type ToughPack, BigPack, and TinyPack using a pointer of type ToughPack*. Of course, the same pointer could also be used to call the volume() function for objects of these class types.

Default Argument Values in Virtual Functions

Default argument values are dealt with at compile time, so you can get unexpected results when you use default argument values with virtual function parameters. If the base class declaration of a virtual function has a default argument value and you call the function through a base pointer, you’ll always get the default argument value from the base class version of the function. Any default argument values in derived class versions of the function will have no effect. We can demonstrate this quickly by altering the previous example to include a parameter with a default argument value for the volume() function in all three classes. Change the definition of the volume() function in the Box class to the following:

In the Carton class it should be as follows:

Finally, in the ToughPack class, you can define volume() as follows and make it public once more:

Obviously, the parameter serves no purpose here other than to demonstrate how default values are assigned.

Once you’ve made these changes to the class definitions, you can try the default parameter values with the main() function from the previous example, in which you uncomment the line that calls the volume() member for the hardcase object directly. The complete program is in the download as Ex14_04. You’ll get this output:

In every instance of when volume() is called except one, the default parameter value output is that specified for the base class function. The exception is when you call volume() using the hardcase object. This is resolved statically to volume() in the ToughPack class, so the default parameter value specified in the ToughPack class is used. All the other calls are resolved dynamically, so the default parameter value specified in the base class applies, even though the function executing is in a derived class.

Using References to Call Virtual Functions

You can call a virtual function through a reference; reference parameters are particularly powerful tools for applying polymorphism, particularly when calling functions that use pass-by-reference. You can pass a base class object or any derived class object to a function with a parameter that’s a reference to the base class. You can use the reference parameter within the function body to call a virtual function in the base class and get polymorphic behavior. When the function executes, the virtual function for the object that was passed as the argument is selected automatically at runtime. We can show this in action by modifying Ex14_02 to call a function that has a parameter of type reference to Box:

Running this program should produce this output:

The class definitions are the same as in Ex14_02. There’s a new global function that calls volume() using its reference parameter to call the volume() member of an object. main() defines the same objects as in Ex14_02 but calls the global showVolume() function with each of the objects to output their volumes. As you see from the output, the correct volume() function is being used in each case, confirming that polymorphism works through a reference parameter.

Each time the showVolume() function is called, the reference parameter is initialized with the object that is passed as an argument. Because the parameter is a reference to a base class, the compiler arranges for dynamic binding to the virtual volume() function.

Polymorphic Collections

Polymorphism becomes particularly interesting when working with so-called polymorphic or heterogeneous collections of objects—both fancy names for collections of base class pointers that contain objects with different dynamic types. Examples of collections include plain C-style arrays, but also the more modern and powerful std::array<> and std::vector<> templates from the Standard Library.

We’ll demonstrate this concept using the Box, Carton, and ToughPack classes from Ex14_03 and a revised main() function:

The output from this example is as follows:

The first part of the program shows how not to create a polymorphic collection. If you assign objects of derived classes in a vector<> of base class objects by value, as always, object slicing will occur. That is, only the subobject corresponding to that base class is retained. The vector in general has no room to store the full object. The dynamic type of the object also gets converted into that of the base class. If you want polymorphism, you know you must always work with either pointers or references.

For our proper polymorphic vector in the second part of the program we could’ve used a vector<> of plain Box* pointers—that is, a vector of type std::vector<Box*>—and store pointers to dynamically allocated Box, ToughPack, and Carton objects in there. The downside of that would’ve been that we’d have had to remember to also delete these Box objects at the end of the program.

You already know that the Standard Library offers so-called smart pointers to help with this. Smart pointers allow us to work safely with pointers without having to worry all the time about deleting the objects.

In the polymorphicBoxes vector, we therefore store elements of type std::unique_ptr<Box>, which are smart pointers to Box objects. The elements can store addresses for objects of Box or any class derived from Box, so there’s an exact parallel with the raw pointers you have seen up to now. Fortunately, as the output shows, polymorphism remains alive and well with smart pointers. When you are creating objects in the free store, smart pointers still give you polymorphic behavior while also removing any potential for memory leaks.

Destroying Objects Through a Pointer

The use of pointers to a base class when you are working with derived class objects is very common because that’s how you can take advantage of virtual functions. If you use pointers or smart pointers to objects created in the free store, a problem can arise when derived class objects are destroyed. You can see the problem if you add destructors to the various Box classes that display a message. Start from the files from Ex14_06, and add a destructor to the Box base class that just displays a message when it gets called:

Do the same for the ToughPack and Carton classes. That is, add destructors of the following form:

and

You’ll need to include the <iostream> header into files where it’s not already included. There is no need to change the main() function. The complete program is present in the code download as Ex14_07. It produces output that ends with the following dozen or so lines (the output that you’ll see before this corresponds to the various Box elements being pushed and sliced into the first vector<>; but this is not the part we want to dissect here):

Clearly we have a failure on our hands. The same base class destructor is called for all six objects, even though four of them are objects of a derived class. This occurs even for the objects stored in the polymorphic vector. Naturally, the cause of this behavior is that the destructor function is resolved statically instead of dynamically, just like with any other function. To ensure that the correct destructor is called for a derived class, we need dynamic binding for the destructors. What we need is virtual destructor functions.

Converting Between Pointers to Class Objects

You can implicitly convert a pointer to a derived class to a pointer to a base class, and you can do this for both direct and indirect base classes. For example, let’s first define a smart pointer to a Carton object:

You can convert the pointer that is embedded in this smart pointer implicitly to a pointer to Box, which is a direct base class of Carton:

The result is a pointer to Box, which is initialized to point to the new Carton object. You know from examples Ex14_05 and Ex14_06 that this also works with references and smart pointers, respectively. A reference to Box, for instance, could be obtained from pCarton as follows:

Let’s look at converting a pointer to a derived class type to a pointer to an indirect base. Suppose you define a CerealPack class with Carton as the public base class. Box is a direct base of Carton, so it is an indirect base of CerealPack. Therefore, you can write the following:

This statement converts the address in pCerealPack from type pointer to CerealPack to type pointer to Box. If you need to specify the conversion explicitly, you can use the static_cast<>() operator:

The compiler can usually expedite this cast because Box is a base class of CerealPack. This would not be legal if the Box class was inaccessible or was a virtual base class.

The result of casting a derived class pointer to a base pointer type is a pointer to the subobject of the destination type. It’s easy to get confused when thinking about casting pointers to class types. Don’t forget that a pointer to a class type can only point to objects of that type or to objects of a derived class type and not the other way round. To be specific, the pointer pCarton could contain the address of an object of type Carton (which could be a subobject of a CerealPack object) or an object of type CerealPack. It cannot contain the address of an object of type Box because a CerealPack object is a specialized kind of Carton, but a Box object isn’t. Figure 14-4 illustrates the possibilities between pointers to Box, Carton, and CerealPack objects.

Despite what we have said so far about casting pointers up a class hierarchy, it’s sometimes possible to make casts in the opposite direction. Casting a pointer down a hierarchy from a base to a derived class is different; whether or not a cast works depends on the type of object to which the base pointer is pointing. For a static cast from a base class pointer such as pBox to a derived class pointer such as pCarton to be legal, the base class pointer must be pointing to a Box subobject of a Carton object. If that’s not the case, the result of the cast is undefined. In other words, bad things will happen.

Figure 14-5 shows static casts from a pointer, pBox, that contains the address of a Carton object. The cast to type Carton* will work because the object is of type Carton. The result of the cast to type CerealPack*, on the other hand, is undefined because no object of this type exists.

If you’re in any doubt about the legitimacy of a static cast, you shouldn’t use it. The success of an attempt to cast a pointer down a class hierarchy depends on the pointer containing the address of an object of the destination type. A static cast doesn’t check whether this is the case, so if you attempt it in circumstances where you don’t know what the pointer points to, you risk an undefined result. Therefore, when you want to cast down a hierarchy, you need to do it differently—in a way in which the cast can be checked at runtime.

Dynamic Casts

A dynamic cast is a conversion that’s performed at runtime. The dynamic_cast<>() operator performs a dynamic cast. You can only apply this operator to pointers and references to polymorphic class types, which are class types that contain at least one virtual function. The reason is that only pointers to polymorphic class types contain the information that the dynamic_cast<>() operator needs to check the validity of the conversion. This operator is specifically for the purpose of converting between pointers or references to class types in a hierarchy. Of course, the types you are casting between must be pointers or references to classes within the same class hierarchy. You can’t use dynamic_cast<>() for anything else. We’ll first discuss casting pointers dynamically.

Casting Pointers Dynamically

There are two kinds of dynamic cast. The first is a “cast down a hierarchy,” from a pointer to a direct or indirect base type to a pointer to a derived type. This is called a downcast . The second possibility is a cast across a hierarchy; this is referred to as a crosscast . Figure 14-6 illustrates these.

For a pointer, pBox, of type Box* that contains the address of a CerealPack object, you could write the downcast shown in Figure 14-6 as follows:

Carton* pCarton {dynamic_cast<Carton*>(pBox)};

The dynamic_cast<>() operator is written in the same way as the static_cast<>() operator. The destination type goes between the angled brackets following dynamic_cast, and the expression to be converted to the new type goes between the parentheses. For this cast to be legal, the Box and Carton classes must contain virtual functions, either as declared or inherited members. For the previous cast to work, pBox must point to either a Carton object or a CerealPack object because only objects of these types contain a Carton subobject. If the cast doesn’t succeed, the pointer pCarton will be set to nullptr.

The crosscast in Figure 14-6 could be written as follows:

Contents* pContents {dynamic_cast<Contents*>(pBox)};

As in the previous case, both the Contents class and the Box class must be polymorphic for the cast to be legal. The cast can succeed only if pBox contains the address of a CerealPack object because this is the only type that contains a Contents object and can be referred to using a pointer of type Box*. Again, if the cast doesn’t succeed, nullptr will be stored in pContents.

Using dynamic_cast<>() to cast down a class hierarchy may fail, but in contrast to the static cast, the result will be nullptr rather than just “undefined.” This provides a clue as to how you can use this. Suppose you have some kind of object pointed to by a pointer to Box and you want to call a nonvirtual member function of the Carton class. A base class pointer only allows you to call the virtual member functions of a derived class, but the dynamic_cast<>() operator can enable you to call a nonvirtual function. If surface() is a nonvirtual member function of the Carton class, you could call it with this statement:

dynamic_cast<Carton*>(pBox)->surface();

This is obviously hazardous and in fact little or no better than using static_cast<>(). You need to be sure that pBox is pointing to a Carton object or to an object of a class that has the Carton class as a base. If this is not the case, the dynamic_cast<>() operator returns nullptr, and the outcome of the call again becomes undefined. To fix this, you can use the dynamic_cast<>() operator to determine whether what you intend to do is valid. Here’s an example:

Carton* pCarton {dynamic_cast<Carton*>(pBox)}

if (pCarton)

  pCarton->surface();

Now you’ll only call the surface() function member if the result of the cast is not nullptr. Note that you can’t remove const-ness with dynamic_cast<>(). If the pointer type you’re casting from is const, then the pointer type you are casting to must also be const. If you want to cast from a const pointer to a non-const pointer, you must first cast to a non-const pointer of the same type as the original using the const_cast<>() operator. Recall that using const_cast<>() is rarely recommended, though. Most of the time there is a good reason you have only a const pointer or reference at your disposal, meaning that side-stepping const-ness using const_cast<> often leads to unexpected or inconsistent states.

Caution

A common mistake is to resort to dynamic casts too often, especially in those cases where polymorphism would be more appropriate. If at any time you find code of the following form, know then that you may have to rethink the class design:

Base* base = ...;                                // Start from a pointer-to-Base

auto derived1 = dynamic_cast<Derived1*>(base);   // Try to dynamic_cast Base* to

auto derived2 = dynamic_cast<Derived2*>(base);   // any number of derived types...

...

auto derivedN = dynamic_cast<DerivedN*>(base);

if (derived1)                                    // A chain of if-else statements...

  derived1->DoThis();

else if (derived2)

  derived2->do_this();

...

else if (derivedN)

  derivedN->doThat();

More often than not, such code should be replaced with a solution based on polymorphism. In our fictional example, you should probably create a function doThisOrThat() in the Base class and override it in any derived class that warrants a different implementation. This entire block of code then collapses to this:

Base* base = ...;

base->doThisOrThat();

Not only is this much shorter, this will even keep working if at some point yet another DerivedX is derived from Base. This is precisely the power of polymorphism. Your code does not need to know about all possible derived classes, now or in the future. All it needs to know about is the interface of the base class. Any attempt to mimic this mechanism using dynamic casts is bound to be inferior.

While our previous example was clearly fictional, unfortunately we do see such patterns emerge all too often in real code. So, we do advise you to be very cautious about this!

A related symptom of dynamic_cast misuse we sometimes encounter, albeit less frequently, is a dynamic cast of a this pointer. Such ill-advised code might, for instance, look something like this:

void Base::DoSomething()

{

  if (dynamic_cast<Derived*>(this))          // NEVER DO THIS!

  {

     /* do something else instead... */

     return;

  }

  ...

}

The proper solution here is to make the DoSomething() function virtual and override it in Derived. Downcasting a this pointer is never a good idea, so please don’t ever do this! The code of a base class has no business referring to derived classes. Any variation of this pattern should be replaced with an application of polymorphism. Tip: In general, leveraging polymorphism may involve you splitting a function into multiple functions, some of which you can then override. If you’re interested, this is again related to the so-called template method design pattern. You can find more information online or in other books about this and other standard patterns.

Calling the Base Class Version of a Virtual Function

You’ve seen that it’s easy to call the derived class version of a virtual function through a pointer or reference to a derived class object—the call is made dynamically. However, what do you do when you actually want to call the base class function for a derived class object?

If you override a virtual base class function in a derived class, you’ll often find that the latter is a slight variation of the former. An excellent example of this is the volume() function of the ToughPack class you’ve been using throughout this chapter:

Obviously, the length * width * height part of this return statement is exactly the formula used to compute the volume() in the base class, Box. In this case, the amount of code you had to retype was limited, but this won’t always be the case. It would therefore be much better if you could simply call the base class version of this function instead.

A plausible first attempt to do so in our example case might be this:

If you write this, however, the volume() override is simply calling itself, which would then be calling itself again, which would then be calling itself again…. You get the idea; this would result in what we called infinite recursion in Chapter 8 and therefore a program crash. The solution is to explicitly instruct the compiler to call the base class version of the function (you can find a ToughPack.h with this modification in Ex14_07A):

Calling the base class version from within a function override like this is common. In some rare cases, though, you may also want to do something similar elsewhere. The Box class provides an opportunity to see why such a call might be required. It could be useful to calculate the loss of volume in a Carton or ToughPack object; one way to do this would be to calculate the difference between the volumes returned from the base and derived class versions of the volume() function. You can force the virtual function for a base class to be called statically by qualifying it with the class name. Suppose you have a pointer pBox that’s defined like this:

You can calculate the loss in total volume for a Carton object with this statement:

The expression pBox->Box::volume() calls the base class version of the volume() function. The class name, together with the scope resolution operator, identifies a particular volume() function, so this will be a static call resolved at compile time.

You can’t use a class name qualifier to force the selection of a particular derived class function in a call through a pointer to the base class. The expression pBox->Carton::volume() won’t compile because Carton::volume() is not a member of the Box class. A call of a function through a pointer is either a static call to a member function of the class type for the pointer or a dynamic call to a virtual function.

Calling the base class version of a virtual function through an object of a derived class can be done analogously. You can calculate the loss in volume for the carton object with this statement:

Calling Virtual Functions from Constructors or Destructors

Ex14_08 illustrates what happens when you call virtual functions from inside constructors and destructors. As always, we start from a Box class with the necessary debugging statements in its relevant members:

We also need a derived class, one that overrides Box::volume():

The actual program is trivial. All it does is create an instance of the derived class ToughPack and then show its volume:

This is the resulting output:

Let’s first focus our attention on the middle line of this output, which is the product of the toughPack.showVolume() function call. ToughPack overrides volume(), so if you call volume() on a ToughPack object, you expect the version of ToughPack to be used, even if this call originates from inside a base class function such as Box::showVolume(). The output clearly shows that this is also what happens. Box::showVolume() prints out a volume of 0.85 * 1 * 2 * 3, or 5.1, as expected.

Now let’s see what happens if you call volume() not from a regular base class member function such as showVolume() but from a base class constructor. The first line in the output shows you that volume() then returns 6. So, it’s clearly the original function of Box that gets called, not the overridden version of ToughPack! Why is that? You’ll recall from the previous chapter that when an object is constructed, all its subobjects are constructed first, including the subobjects of all its base classes. While initializing such a subobject—for instance, the Box subobject of our ToughPack—the object of the derived class will therefore at most be partially initialized. It would in general be extremely dangerous to call member functions on an object whose subobjects have not yet been fully initialized. This is why all function calls from inside a constructor, including those of virtual members, are always resolved statically.

Conversely, when destructing an object, all its subobjects are destructed in the reverse order in which they were constructed. So, by the time the destructor of the base class subobject is called, the derived class is already partially destructed. It would thus again be a bad idea to call members of this derived object. So, all function calls in destructors are thus resolved statically as well.

Abstract Classes

Even though it has a member variable, a constructor, and even a member function with an implementation, the Shape class is an incomplete description of an object because the area() and scale() functions are not defined. Therefore, you’re not allowed to create instances of the Shape class; the class exists purely for the purpose of deriving classes from it. Because you can’t create objects of an abstract class, you cannot pass it by value to a function; a parameter of type Shape will not compile. Similarly, you cannot return a Shape by value from a function. However, pointers or references to an abstract class can be used as parameter or return types, so types such as Shape* and Shape& are fine in these settings. It is essential that this should be the case to get polymorphic behavior for derived class objects.

This raises the question, “If you can’t create an instance of an abstract class, then why does the abstract class contain a constructor?” The answer is that the constructor for an abstract class is there to initialize its member variables. The constructor for an abstract class will be called by a derived class constructor, implicitly or from the constructor initialization list. If you try to call the constructor for an abstract class from anywhere else, you’ll get an error message from the compiler.

Because the constructor for an abstract class can’t be used generally, it’s a good idea to declare it as a protected member of the class, as we have done for the Shape class. This allows it to be called in the initialization list for a derived class constructor but prevents access to it from anywhere else. Note that a constructor for an abstract class must not call a pure virtual function; the effect of doing so is undefined.

Any class that derives from the Shape class must define both the area() function and the scale() function. If it doesn’t, it too is an abstract class. More specifically, if any pure virtual function of an abstract base class isn’t defined in a derived class, then the pure virtual function will be inherited as such, and the derived class will also be an abstract class.

To illustrate this, you could define a new class called Circle, which has the Shape class as a base:

The area() and scale() functions are defined, so this class is not abstract. If either function were not defined, then the Circle class would be abstract. The class includes a constructor, which initializes the base class subobject by calling the base class constructor.

Of course, an abstract class can contain virtual functions that it does define and functions that are not virtual. An example of the former was the move() function in Shape. It can also contain any number of pure virtual functions.

Let’s look at a working example that uses an abstract class. We’ll define a new version of the Box class with the volume() function declared as a pure virtual function. As a polymorphic base class, it of course needs a virtual destructor as well:

Because Box is now an abstract class, you can no longer create objects of this type. This would not have been possible even if we hadn’t made the constructor protected. Because these constructors are only intended for use in derived classes, however, it makes sense to declare them protected. The Carton and ToughPack classes in this example are the same as in Ex14_06. They both define the volume() function, so they aren’t abstract, and we can use objects of these classes to show that the virtual volume() functions are still working as before:

This generates the following output:

Declaring volume() to be a pure virtual function in the Box class ensures that the volume() function members of the Carton and ToughPack classes are also virtual. Therefore, you can call them through a pointer to the base class, and the calls will be resolved dynamically. The output for the ToughPack and Carton objects shows that everything is working as expected. The Carton and ToughPack class constructors still call the Box class constructor that is now protected in their initialization lists.

Abstract Classes as Interfaces

Sometimes an abstract class arises simply because a function has no sensible definition in the context of the class and has a meaningful interpretation only in a derived class. However, there is another way of using an abstract class. An abstract class that contains only pure virtual functions—no member variables or other functions—can be used to define what in object-oriented terminology is often called an interface. It would typically represent a declaration of a set of related functions that supported a particular capability—a set of functions for communications through a modem, for example. While other programming languages such as Java and C# have specific class-like language constructs for this, in C++ one defines an interface using an abstract class consisting solely of pure virtual functions. As we’ve discussed, a class that derives from such an abstract base class must define an implementation for each virtual function, but the way in which each virtual function is implemented is specified by whoever is implementing the derived class. The abstract class fixes the interface, but the implementation in the derived class is flexible.

Because the abstract Shape and Box classes from the previous section have member variables, they’re not really interface class. An example of an interface would be the following Vessel class, defined in Vessel.h. All it does is specify that any Vessel has a volume, which may be obtained from its (pure virtual) volume() member function:

There could be any number of classes implementing the Vessel interface. All would implement the interface’s volume() function in their own way. Our first Vessel class will be, naturally, our trusty old Box class:

This makes any classes derived from Box valid Vessels as well. You can, for instance, use the Carton and ToughPack classes from Ex14_09 (although you can and should again call Box::volume() now from within its ToughPack override since now this base class function is no longer pure virtual).

Of course, you can also add another class derived from Vessel. One example would be a class that defines a can. Here is a class definition you can place in Can.h:

This defines Can objects that represent regular cylindrical cans, such as a beer can. The class uses the same PI macro we discussed earlier. Note that it might be better to define such constants in a separate header, say math_constants.h, instead. This would then allow you to reuse these constants in multiple header and source files.

You can find the program that glues everything together in Ex14_11.cpp:

This generates the following output:

This time around, we used a vector of raw pointers to Vessel objects to exercise the virtual functions. The output shows that all the polymorphic calls of the volume() function work as expected.

You have a three-level class hierarchy in this example, as shown in Figure 14-8.

Recall that if a derived class fails to define a function that’s declared as a pure virtual function in the base class, then the function will be inherited as a pure virtual function, and this will make the derived class an abstract class. You can demonstrate this effect by removing the const declaration from either the Can or the Box class. This makes the function different from the pure virtual function in the base class, so the derived class inherits the base class version, and the program won’t compile.