Hierarchies

In previous chapters, we defined the Box class to represent a rectilinear box. The defining properties of a Box object were just the three orthogonal dimensions. You can apply this basic definition to the many different kinds of rectangular boxes that you find in the real world: cardboard cartons, wooden crates, candy boxes, cereal boxes, and so on. All these have three orthogonal dimensions, and in this way they’re just like generic Box objects. However, each of them has other properties such as the things they’re designed to hold, the material from which they’re made, or the labels printed on them. You could describe them as specialized kinds of Box objects.

For example, a Carton class could have the same properties as a Box object—namely, the three dimensions—plus the additional property of its composite material. You could then specialize even further by using the Carton definition to describe a FoodCarton class, which is a special kind of Carton that is designed to hold food. A FoodCarton object will have all the properties of a Carton object and an additional member to model the contents. Of course, a Carton object has the properties of a Box object, so a FoodCarton object will have those too. Figure 13-1 shows the connections between classes that express these relationships.

The Carton class is an extension of the Box class. You might say that the Carton class is derived from the Box class. In a similar way, the FoodCarton class has been derived from the Carton class. It’s common to indicate this relationship diagrammatically by using an arrow pointing toward the more general class in the hierarchy. This notation is used also by the Unified Modeling Language (UML), the de facto standard way for visualizing the design of object-oriented software programs. Figure 13-1 is a simplified UML class diagram, with some additional annotations to clarify.

In specifying one class in terms of another, you’re developing a hierarchy of interrelated classes. One class is derived from another by adding extra properties—in other words, by specialization—making the new class a specialized version of the more general class. In Figure 13-1, each class in the hierarchy has all the properties of the Box class, which illustrates precisely the mechanism of class inheritance. You could define the Box, Carton, and FoodCarton classes quite independently of each other, but by defining them as related classes, you gain a tremendous amount. Let’s look at how this works in practice.

Inheritance vs. Aggregation

Class inheritance isn’t just a means of getting members of one class to appear in another. There’s an important idea that underpins the whole concept: derived class objects should be sensible specializations of base class objects. To decide whether this is the case in a specific instance, you can apply the is a test, which is that any derived class object is a base class object. In other words, a derived class should define a subset of the objects that are represented by the base class. We explained earlier that a Dog class might be derived from an Animal class because a dog is an animal; more precisely, a Dog object is a reasonable representation of a particular kind of Animal object. On the other hand, a Table class shouldn’t be derived from the Dog class. Although Table and Dog objects share a common attribute in that they both usually have four legs, a Table object can’t really be considered to be a Dog in any way, or vice versa.

The is a test is an excellent first check, but it’s not infallible. For example, suppose you define a Bird class that among other things reflects the fact that most birds can fly. Now, an ostrich is a bird, but it’s nonsense to derive a class Ostrich from the Bird class because ostriches can’t fly! The problem arises because of a poor definition for Bird objects. You really need a base class that doesn’t have the ability to fly as a property. You can then derive two subclasses, one for birds that can fly and the other for birds that can’t. If your classes pass the is a test, you should double-check by asking whether there is anything we can say about (or demand of) the base class that’s inapplicable to the derived class. If there is, then the derivation probably isn’t sound. Deriving Dog from Animal is sensible, but deriving Ostrich from Bird as we described it, isn’t.

If classes fail the is a test, then you probably shouldn’t use class derivation. In this case, you could check the has a test. A class object passes the has a test if it contains an instance of another class. You can accommodate this by including an object of the second class as a member variable of the first. The Automobile and Engine classes that we mentioned earlier are an example. An Automobile object would have an Engine object as a member variable; it may well have other major subassemblies as member variables of types such as Transmission and Differential. This type of relationship is called aggregation .

If the child object contained in a parent object cannot exist independently of its parent, their relation is called composition instead of aggregation. An example of composition would be the relation between a House and a Room, if Rooms cannot exist without a House. If you delete a House, all its Rooms are typically deleted as well. An example of aggregation is the relation Class–Student. Students generally do not cease to exist if their Class is cancelled.

Of course, what is appropriate to include in the definition of a class depends on the application. Sometimes, class derivation is used simply to assemble a set of capabilities so that the derived class is an envelope for packaging a given set of functions. Even then, the derived class generally represents a set of functions that are related in some way. Let’s see what the code to derive one class from another looks like.

Deriving Classes

Here’s a simplified version of the Box class from Chapter 12:

We can define a Carton class based on the Box class. A Carton object will be similar to a Box object but with an extra member variable that indicates the material from which it’s made. We’ll define Carton as a derived class, using the Box class as the base class:

The #include directive for the Box class definition is necessary because it is the base class for Carton. The first line of the Carton class definition indicates that Carton is derived from Box. The base class name follows a colon that separates it from the derived class name, Carton in this case. The public keyword is a base class access specifier that determines how the members of Box can be accessed from within the Carton class. We’ll discuss this further in a moment.

In all other respects, the Carton class definition looks like any other. It contains a new member, material, which is initialized by the constructor. The constructor defines a default value for the string describing the material of a Carton object so that this is also the no-arg constructor for the Carton class. Carton objects contain all the member variables of the base class, Box, plus the additional member variable, material. Because they inherit all the characteristics of a Box object, Carton objects are also Box objects. There’s a glaring inadequacy in the Carton class in that it doesn’t have a constructor defined that permits the values of inherited members to be set, but we’ll return to that later. Let’s first see how these class definitions work in an example:

We get the following output:

The main() function creates a Box object and two Carton objects and outputs the number of bytes occupied by each object. The output shows what you would expect—that a Carton object is larger than a Box object. A Box object has three member variables of type double; each of these occupies 8 bytes on nearly every machine, so that’s 24 bytes in all. Both of the Carton objects are the same size: 56 bytes. The additional memory occupied by each Carton object is down to the member variable material, so it’s the size of a string object that contains the description of the material. The output of the volumes for the Carton objects shows that the volume() function is indeed inherited in the Carton class and that the dimensions have the default values of 1.0. The next statement shows that the accessor functions are inherited too and can be called for a derived class object.

Uncommenting either of the last two statements results in an error message from the compiler. The member variables that are inherited by the Carton class were private in the base class, and they are still private in the derived class, Carton, so they cannot be accessed from outside the class. There’s more, though. Try adding this function to the Carton class definition as a public member:

This won’t compile. The reason is that although the member variables of Box are inherited, they are inherited as private members of the Box class. The private access specifier determines that members are totally private to the class. Not only can they not be accessed from outside the Box class, they also cannot be accessed from inside a class that inherits them.

Access to inherited members of a derived class object is not only determined by their access specification in the base class but by both the access specifier in the base class and the access specifier of the base class in the derived class. We’ll go into that a bit more next.

Access Specifiers and Class Hierarchies

Figure 13-4 shows how the accessibility of inherited members is affected only by the access specifiers of the members in the base class. Within a derived class, public and protected base class members are always accessible, and private base class members are never accessible. From outside the derived class, only public base class members may be accessed, and this is the case only when the base class is declared as public.

Figure 13-5 shows how the public and protected members of a base class can be passed on as protected members of another derived class. Members of a privately inherited base class won’t be accessible in any further derived class. In the majority of instances, the public base class access specifier is most appropriate with the base class member variables declared as either private or protected. In this case, the internals of the base class subobject are internal to the derived class object and are therefore not part of the public interface for the derived class object. In practice, because the derived class object is a base class object, you’ll want the base class interface to be inherited in the derived class, and this implies that the base class must be specified as public.

Constructors are not normally inherited for very good reasons, but you’ll see later in this chapter how you can cause constructors to be inherited in a derived class.

Choosing Access Specifiers in Class Hierarchies

You have two aspects to consider when defining a hierarchy of classes: the access specifiers for the members of each class and the base class access specifier in each derived class. The public members of a class define the external interface to the class, and this shouldn’t normally include any member variables. In fact:

Therefore, always make member variables private, unless you have a good reason not do so.

Member functions that aren’t part of the public interface of a class should not be directly accessible from outside the class either, which means that they should be private or protected. Which access specification you choose for a particular function then depends on whether you want to allow access from within a derived class. If you do, use protected; otherwise, use private.

Changing the Access Specification of Inherited Members

You might want to exempt a particular base class member from the effects of a protected or private base class access specification. This is easier to understand with an example. Suppose you derive the Carton class from the Box class in Ex13_01 but with Box as a private base class. All members inherited from Box will now be private in Carton, but you’d like the volume() function to remain public in the derived class, as it is in the base class. You can restore the public status for a particular inherited member that was public in the base class with a using declaration.

This is essentially the same as the using declaration for namespaces. You can force the volume() function to be public in the derived class by defining the Carton class like this:

The class definition defines a scope, and the using declaration within the class definition introduces a name into that class scope. The member access specification applies to the using declaration, so the volume name is introduced into the public section of the Carton class so it overrides the private base class access specification for the volume() member of the base class. The function will be inherited as public in the Carton class, not as private. Ex13_01A in the code download shows this working.

There are several points to note here. First, when you apply a using declaration to the name of a member of a base class, you must qualify the name with the base class name, because this specifies the context for the member name. Second, note that you don’t supply a parameter list or a return type for a member function—just the qualified name. This implies that overloaded functions always come as a package deal. Third, the using declaration also works with inherited member variables in a derived class.

You can use a using declaration to override an original public or protected base class access specifier in a base class. For example, if the volume() function was protected in the Box base class, you could make it public in the derived Carton class with the same using declaration in a public section of Carton. However, you can’t apply a using declaration to relax the specification of a private member of a base class because private members cannot be accessed in a derived class.

The Copy Constructor in a Derived Class

You already know that the copy constructor is called when an object is created and initialized with another object of the same class type. The compiler will supply a default copy constructor that creates the new object by copying the original object member by member if you haven’t defined your own version. Now let’s examine the copy constructor in a derived class. To do this, we’ll add to the class definitions in Ex13_02. First, we’ll add a copy constructor to the base class, Box, by inserting the following code in the public section of the class definition:

This initializes the member variables by copying the original values and generates some output to track when the copy constructor is called.

Here’s a first attempt at a copy constructor for the Carton class:

Let’s see if this works (it won’t!):

This produces the following output:

All is not as it should be. Clearly the volume of cartonCopy isn’t the same as carton, but the output also shows the reason for this. To copy the carton object, you call the copy constructor for the Carton class. The Carton copy constructor should make a copy of the Box subobject of carton, and to do this it should call the Box copy constructor. However, the output clearly shows that the default Box constructor is being called instead.

The Carton copy constructor won’t call the Box copy constructor if you don’t tell it to do so. The compiler knows that it has to create a Box subobject for the object carton, but if you don’t specify how, the compiler won’t second-guess your intentions—it will just create a default base object.

The obvious fix for this is to call the Box copy constructor in the initialization list of the Carton copy constructor. Simply change the copy constructor definition to this:

The Box copy constructor is called with the carton object as an argument. The carton object is of type Carton, but it is also a perfectly good Box object. The parameter for the Box class copy constructor is a reference to a Box object, so the compiler will pass carton as type Box&, which will result in only the base part of carton being passed to the Box copy constructor. If you compile and run the example again, the output will be as follows:

The output shows that the constructors are called in the correct order. In particular, the Box copy constructor is called to create the Box subobject of carton before the Carton copy constructor. By way of a check, you can see that the volumes of the carton and cartonCopy objects are now identical.

The Default Constructor in a Derived Class

You know that the compiler will not supply a default no-arg constructor if you define one or more constructors for a class. You also know that you can tell the compiler to insert a default constructor in any event using the default keyword. You could replace the definition of the no-arg constructor in the Carton class definition in Ex13_02 with this statement:

Now the compiler will supply a definition, even though you have defined other constructors. The definition that the compiler supplies for a derived class calls the base class constructor, so it looks like this:

This implies that if the compiler supplies the no-arg constructor in a derived class, a non-private no-arg constructor must exist in the base class. If it doesn’t, the code will not compile. You can easily demonstrate this either by removing the no-arg constructor from the Box class in Ex13_02 or by making it private. With the compiler-supplied default constructor specified for the Carton class, the code will no longer compile. Every derived class constructor calls a base class constructor. If a derived class constructor does not explicitly call a base constructor in its initialization list, the no-arg constructor will be called.

Inheriting Constructors

Base class constructors are not normally inherited in a derived class. This is because a derived class typically has additional member variables that need to be initialized, and a base class constructor would have no knowledge of these. However, you can cause constructors to be inherited from a direct base class by putting a using declaration in the derived class. Here’s how a version of the Carton class from Ex13_02 could be made to inherit the Box class constructors:

If the Box class definition is the same as in Ex13_02, the Carton class will inherit two constructors: Box(double, double, double) and Box(double). The constructors in the derived class will look like this:

Each inherited constructor has the same parameter list as the base constructor and calls the base constructor in its initialization list. The body of each constructor is empty. You can add further constructors to a derived class that inherits from its direct base, as the Carton class example illustrates.

Unlike regular member functions, (non-private) constructors are inherited using the same access specifier as the corresponding constructor in the base class. So, even though the using Box::Box declaration is part of the implicitly private section of the Carton class, the constructors inherited from Box are both public. If the Box class would’ve had protected constructors, these would’ve been inherited as protected constructors in Carton as well.

Notice that one constructor of Box is flagrantly missing from the list of inherited constructors: the default constructor. That is, the using declaration did not cause a default constructor of the following form to be inherited:

Default constructors are never inherited. And because Carton explicitly defines a constructor (inherited constructors do not count here, by the way), the compiler did not generate a default default constructor either. Technically speaking, copy constructors are not inherited either, but you won’t notice this as the compiler mostly generates a default copy constructor anyway. You could try this by modifying Ex13_02 to create the following objects in main():

The resulting program is available online as Ex13_04. The output statements in the Box constructors will show that they are indeed called to create the first three objects. Of course, if you want Carton to have a default constructor, you could always instruct the compiler to generate one using the default keyword.

The Order in Which Destructors Are Called

The order of destructor calls for a derived class object is the reverse of the constructor call sequence for the object. The derived class destructor is called first, and then the base class destructor is called, just as in the example. Figure 13-6 illustrates the case of a three-level class hierarchy.

For an object with several levels of derivation classes, this order of destructor calls runs through the hierarchy of classes, starting with the most derived class destructor and ending with the destructor for the most base class.

Multiple Base Classes

Multiple inheritance involves two or more base classes being used to derive a new class, so things are immediately more complicated. The idea of a derived class being a specialization of its base leads in this case to the notion that the derived class defines an object that is a specialization of two or more different and independent class types concurrently. In practice, multiple inheritance is rarely used in this way. More often, multiple base classes are used to add the features of the base classes together to form a composite object containing the capabilities of its base classes, sometimes referred to as mixin programming. This is usually for convenience in an implementation rather than to reflect any particular relationships between objects. For example, you might consider a programming interface of some kind—for graphics programming, perhaps. A comprehensive interface could be packaged in a set of classes, each of which defines a self-contained interface that provides some specific capability, such as drawing two-dimensional shapes. You can then use several of these classes as bases for a new class that provides precisely the set of capabilities you need for an application.

To explore some of the implications of multiple inheritance, we’ll start with a hierarchy that includes the Box and Carton classes. Suppose you need a class that represents a package containing dry contents, such as a carton of cereal. It’s possible to do this by using single inheritance, deriving a new class from the Carton class, and adding a member variable to represent contents, but you could also do it using the hierarchy illustrated in Figure 13-8.

The definition of the CerealPack class looks like this:

Each base class is specified after the colon in the class header, and the base classes are separated by commas. Each base class has its own access specifier, and if you omit the access specifier, private is assumed, the same as with single inheritance. The CerealPack class will inherit all the members of both base classes, so this will include the members of the indirect base, Box. As in the case of single inheritance, the access level of each inherited member is determined by two factors: the access specifier of the member in the base class and the base class access specifier. A CerealPack object contains two subobjects, a Contents subobject and a Carton subobject that has a further subobject of type Box.

Inherited Member Ambiguity

Multiple inheritance can create problems. We’ll put together an example that will show the sort of complications you can run into. The Box class is the same as in Ex13_05, but we’ll extend the Carton class from that example a little:

We’ve added two member variables that record the thickness and density of the material from which the Carton object is made; a new constructor that allows all member variables to be set; and a new member function, getWeight(), which calculates the weight of an empty Carton object. The new constructor calls another Carton class constructor in its initialization list, so it is a delegating constructor, as you saw in Chapter 11. A delegating constructor cannot have further initializers in the list, so the values for density and thickness have to be set in the constructor body.

The Contents class will describe an amount of a dry product, such as breakfast cereal, that can be contained in a carton. The class will have three member variables: name, volume, and density (in pounds per cubic inch). In practice, you would probably include a set of possible cereal types, complete with their densities, so that you could validate the data in the constructor, but we’ll ignore such niceties in the interest of keeping things simple. Here’s the class definition along with the preprocessing directives that you need in the header file, Contents.h:

In addition to the constructors and the destructor, the class has a public member function, getWeight(), to calculate the weight of the contents. Note how the name member is initialized in the member initializer list with the parameter value that has the same name. This is just to illustrate that this is possible—not a recommended approach. We’ll define the CerealPack class with the Carton and Contents classes as public base classes:

This class inherits from both the Carton and Contents classes. The constructor requires only the external dimensions and the cereal type. The material for the Carton object is set in the Carton constructor call, in the initialization list. A CerealPack object will contain two subobjects corresponding to the two base classes. Each subobject is initialized through constructor calls in the initialization list for the CerealPack constructor. Note that the volume member variable of the Contents class is zero by default, so, in the body of the CerealPack constructor, the value is calculated from the size of the carton. The reference to the volume member variable inherited from the Contents class must be qualified here because it’s the same as the name of the function inherited from Box via Carton. You’ll be able to trace the order of constructor and destructor calls from the output statements here and in the other classes.

Let’s try creating a CerealPack object and calculate its volume and weight with the following simple program:

Unfortunately, there’s a problem. The program won’t compile. The difficulty is that we have foolishly used some nonunique function names in the base classes. The name volume is inherited as a function from Box and as a member variable from Contents , and the getWeight() function is inherited from Carton and from Contents in the CerealPack class. There’s more than one ambiguity problem.

Of course, when writing classes for use in inheritance, you should avoid duplicating member names in the first instance. The ideal solution to this problem is to rewrite your classes. If you are unable to rewrite the classes—if the base classes are from a library of some sort, for example—then you would be forced to qualify the function names in main(). You could amend the output statement in main() to get the code to work:

With this change, the program will compile and run, and it will produce the following output:

You can see from the output that this cereal will give you a solid start to the day—a single packet weighs more than six pounds. You can also see that the constructor and destructor call sequences follow the same pattern as in the single inheritance context: the constructors run down the hierarchy from most base to most derived, and the destructors run in the opposite order. The CerealPack object has subobjects from both legs of its inheritance chain, and all the constructors for these subobjects are involved in the creation of a CerealPack object.

An alternative way of making Ex13_06 compile, by the way, is by adding casts to a reference to either of the base classes (we cast to a reference and not the class type itself to avoid the creation of a new object):

A working version along these lines is in the code download as Ex13_06A.

But, wait, we’re not done yet! There’s yet another way of ensuring that this compiles—one that is definitely worth mentioning as well. Clearly it is inconvenient that users of your CerealPack class always have to disambiguate the volume() and getWeight() members. Luckily, you can typically prevent this from happening. Suppose we insist in the insanity that a CerealPack’s volume should always be computed using the volume() member of Carton and its weight using the getWeight() member of Contents. Then you could stipulate this property as such in the definition of its class (see Ex13_06B) as follows:

Earlier this chapter you encountered a similar use of the using keyword to inherit constructors from the base class. In this case you use it to cherry-pick from which base class a multiply inherited member function needs to be inherited. Now CerealPack users—or breakfast eaters, as they are more commonly known as—can simply write this:

Clearly this last option is thus preferred whenever there is a clear answer as to which multiply inherited members should be used. If you disambiguate the inheritance already in the class definition, it saves the users of your class the hassle of fighting against the compiler errors that would otherwise surely follow.

Repeated Inheritance

The previous example demonstrated how ambiguities can occur when member names of base classes are duplicated. Another ambiguity can arise in multiple inheritances when a derived object contains multiple versions of a subobject of one of the base classes. You must not use a class more than once as a direct base class, but it’s possible to end up with duplication of an indirect base class. Suppose the Box and Contents classes in Ex13_06 were themselves derived from a class Common. Figure 13-9 shows the class hierarchy that is created.

The CerealPack class inherits all the members of both the Contents and Carton classes. The Carton class inherits all the members of the Box class, and both the Box and Contents classes inherit the members of the Common class. Thus, as Figure 13-9 shows, the Common class is duplicated in the CerealPack class. The effect of this on objects of type CerealPack is that every CerealPack object will have two subobjects of type Common. The complications and ambiguities that arise from such repeated inheritance are often referred to as the diamond problem—named after the shape of inheritance diagrams such as Figure 13-9.

It is conceivable that you actually want to allow the duplication of the Common class. In this case, you must qualify each reference to the Common class member so that the compiler can tell which inherited member you’re referring to in any particular instance. In this case, you can do this by using the Carton and Contents class names as qualifiers because each of these classes contains a unique subobject of type Common. Of course, to call the Common class constructors when you’re creating a CerealPack object, you would also need qualifiers to specify which of the two base objects you were initializing. More typically, though, you would want to prevent the duplication of a base class, so let’s see how to do that.

Virtual Base Classes

To avoid duplication of a base class, you must identify to the compiler that the base class should appear only once within a derived class. You do this by specifying the class as a virtual base class using the virtual keyword. The Contents class would be defined like this:

The Box class would also be defined with a virtual base class:

Now any class that uses the Contents and Box classes as direct or indirect bases will inherit the other members of the base classes as usual but will inherit only one instance of the Common class. The derived CerealPack class would inherit only a single instance of the Common base class. Because there is no duplication of the members of Common in the CerealPack class, no qualification of the member names is needed when referring to them in the derived class.