Encapsulation

In general, the definition of an object of a given type requires a combination of a specific number of different properties—the properties that make the object what it is. An object contains a precise set of data values that describe the object in sufficient detail for your needs. For a box, it could be just the three dimensions of length, width, and height. For an aircraft carrier, it is likely to be much more. An object can also contain a set of functions that operate on it—functions that use or change the properties, for example, or provide further characteristics of an object such as the volume of a box. The functions in a class define the set of operations that can be applied to an object of the class type, in other words, what you can do with it or to it. Every object of a given class incorporates the same combination of things, specifically, the set of data values as member variables of the class that characterize an object and the set of operations as member functions of the class. This packaging of data values and functions within an object is referred to as encapsulation .¹

Figure 11-1 illustrates this with the example of an object that represents a loan account with a bank. Every LoanAccount object has its properties defined by the same set of member variables; in this case, one holds the outstanding balance, and the other holds the interest rate. Each object also contains a set of member functions that define operations on the object. The object shown in Figure 11-1 has three member functions: one to calculate interest and add it to the balance and two for managing credit and debit accounting entries. The properties and operations are all encapsulated in every object of the type LoanAccount. Of course, this choice of what makes up a LoanAccount object is arbitrary. You might define it quite differently for your purposes, but however you define the LoanAccount type, all the properties and operations that you specify are encapsulated within every object of the type.

Note that we said earlier that the data values defining an object needed to be “sufficient for your needs,” not “sufficient to define the object in general.” A person could be defined simply, perhaps just by the name, address, and phone number if you were writing an address book application. A person as a company employee or as a medical patient is likely to be defined by many more properties, and many more operations would be required. You just decide what you need in the contexts in which you intend to use the object.

Data Hiding

Of course, the bank wouldn’t want the balance for a loan account (or the interest rate for that matter) changed arbitrarily from outside an object. Permitting this would be a recipe for chaos. Ideally, the member variables of a LoanAccount object are protected from direct outside interference and are only modifiable in a controlled way. The ability to make the data values for an object generally inaccessible is called data hiding or information hiding .

Figure 11-2 shows data hiding applied to a LoanAccount object. With a LoanAccount object, the member functions of the object can provide a mechanism that ensures any changes to the member variables follow a particular policy and that the values set are appropriate. Interest shouldn’t be negative, for instance, and generally, the balance should reflect the fact that money is owed to the bank, not the reverse.

Data hiding is important because it is necessary if you are to maintain the integrity of an object. If an object is supposed to represent a duck, it should not have four legs; the way to enforce this is to make the leg count inaccessible, in other words, to “hide” the data. Of course, an object may have data values that can legitimately vary, but even then you often want to control the range; after all, a duck doesn’t usually weigh 300 pounds, and its weight is definitely rarely zero or negative. Hiding the data belonging to an object prevents it from being accessed directly, but you can provide access through functions that are members of the object, either to alter a data value in a controlled way or simply to obtain its value. Such functions can check that the change they’re being asked to make is legal and within prescribed limits where necessary.

You can think of the member variables as representing the state of the object, and the member functions that manipulate them as representing the object’s interface to the outside world. Using the class then involves programming using the functions declared as the interface. A program using the class interface is dependent only on the function names, parameter types, and return types specified for the interface. The internal mechanics of these functions don’t affect the rest of the program that is creating and using objects of the class. That means it’s important to get the class interface right at the design stage. You can subsequently change the implementation to your heart’s content without necessitating any changes to programs that use the class.

For instance, as a program evolves over time, you may need to change the member variables that constitute an object’s state. Instead of storing an interest rate in each individual LoanAccount object, for example, you may want to change it so that every LoanAccount object refers to an object of a new class AccountType and store the interest rate in there instead. Figure 11-3 illustrates this redesigned representation of LoanAccount objects.

LoanAccount objects now no longer store their interest rate themselves but instead point to an AccountType, which stores all necessary member variables for calculating an account’s interest. The calcInterest() member function of LoanAccount therefore calls upon the associated AccountType to do the actual calculation; for this, all the latter needs from an account is its current balance. This more object-oriented design allows you to easily modify the interest rates of all LoanAccounts pointing to the same AccountType all at once or to change the type of an account without re-creating it.

The main point we want to make with this example is that even though both the internal representation (the interestRate member) and the workings (the calcInterest() member) of a LoanAccount have changed drastically, its interface to the outside world remained constant. As far as the rest of the program is concerned, it therefore appears as if nothing has changed at all. Such an overhaul of a LoanAccount’s representation and logic would’ve been much harder if code from outside of its class definition would’ve been accessing the old, now-removed interestRate member variable of LoanAccounts directly. We would then have had to rework all code using LoanAccount objects as well. Thanks to data hiding, external code can only access member variables through well-defined interface functions. So, all we had to do is to redefine these member functions; we didn’t have to worry about the rest of the program.

Notice moreover that because external code could obtain the annual interest only through the calcInterest() interface function, it was trivial for us to introduce an extra “loyalty premium” and use this during interest calculations. This again would’ve been near impossible if external code would’ve been reading the old interestRate member directly to calculate interests themselves.

Hiding the data within an object is not mandatory, but it’s generally a good idea. In a way, direct access to the values that define an object undermines the whole idea of object-oriented programming. Object-oriented programming is supposed to be programming in terms of objects, not in terms of the bits that make up an object. While this may sound rather abstract, we have already seen at least two very good, concrete reasons to consistently hide an object’s data and to only access or manipulate it through the functions in its interface:

• Data hiding facilitates maintaining the integrity of an object. It allows you to make sure that an object’s internal state—the combination of all its member variables—remains valid at all times.

• Data hiding, combined with a well-thought-out interface, allows you to rework both an object’s internal representation (that is, its state) and the implementation of its member functions (that is, its behavior) without having to rework the rest of the program as well. In object-oriented speak we say that data hiding reduces the coupling between a class and the code that uses it. Interface stability is, of course, even more critical if you are developing a software library that is used by external customers.

A third motivation for accessing member variables only through interface functions is that it allows you to inject some extra code into these functions. Such code could add an entry to a log file marking the access or change, could make sure the data can be accessed safely by multiple callers at the same time (we’ll briefly discuss C++’s concurrency facilities near the end of the book), or could notify other objects that some state has been modified (these other objects could then, for instance, update the user interface of your application, say to reflect updates to a LoanAccount’s balance), and so on. None of this would be possible if you allow external code to access member variables directly.

A fourth and final motivation for not allowing direct access to data variables is that it complicates debugging. Most development environments support the concept of breakpoints. Breakpoints are user-specified points during debugging runs of the code where the execution becomes paused, allowing you to inspect the state of your objects. While some environments have more advanced functionality to put breakpoints if a particular member variable changes, putting breakpoints on function calls or specific lines of code inside functions is much easier.

In this section, we created an extra AccountType class to facilitate working with different types of accounts. This is by no means the only way to model these real-world concepts into classes and objects. In the next section we’ll present a powerful alternative called inheritance. Which design you should use will depend on the exact needs of your concrete application.

Inheritance

Inheritance is the ability to define one type in terms of another. For example, suppose you have defined a BankAccount type that contains members that deal with the broad issues of bank accounts. Inheritance allows you to create the LoanAccount type as a specialized kind of BankAccount. You could define a LoanAccount as being like a BankAccount, but with a few extra properties and functions of its own. The LoanAccount type inherits all the members of BankAccount, which is referred to as its base class. In this case, you’d say that LoanAccount is derived from BankAccount.

Each LoanAccount object contains all the members that a BankAccount object does, but it has the option of defining new members of its own or of redefining the functions it inherits so that they are more meaningful in its context. Redefining a base class’s function in a derived class is called overriding ; the latter function is said to override the former. This last ability is very powerful, as you’ll see.

Extending the current example, you might also want to create a new CheckingAccount type by adding different characteristics to BankAccount. This situation is illustrated in Figure 11-4.

Both of the LoanAccount and CheckingAccount types are defined so that they are derived from the type BankAccount. They inherit the member variables and member functions of BankAccount, but they are free to define new characteristics that are specific to their own type.

In this example, CheckingAccount has added a member variable called overdraftFacility that is unique to itself, and both the derived classes can override any of the member functions that they inherit from the base class. It’s likely they would override calcInterest(), for example, because calculating and dealing with the interest for a checking account involves something rather different than doing it for a loan account.

Polymorphism

Polymorphism means the ability to assume different forms at different times. Polymorphism in C++ always involves calling a member function of an object using either a pointer or a reference. Such function calls can have different effects at different times—sort of Jekyll and Hyde function calls. The mechanism works only for objects of types that are derived from a common base type, such as the BankAccount type. Polymorphism means that objects belonging to a “family” of inheritance-related classes can be passed around and operated on using base class pointers and references.

The LoanAccount and CheckingAccount objects can both be passed around using a pointer or reference to BankAccount. The pointer or reference can be used to call the inherited member functions of whatever object it refers to. The idea and implications of this will be easier to appreciate if we look at a specific case.

Suppose you have the LoanAccount and CheckingAccount types defined as before, based on the BankAccount type. Suppose further that you have defined objects of these types, debt and cash, respectively, as illustrated in Figure 11-5. Because both types are based on the BankAccount type, a variable of type pointer to BankAccount, such as pAcc in Figure 11-5, can store the address of either of these objects.

The beauty of polymorphism is that the function called by pAcc->calcInterest() varies depending on what pAcc points to. If it points to a LoanAccount object, then the calcInterest() function for that object is called, and interest is debited from the account. If it points to a CheckingAccount object, the result is different because the calcInterest() function for that object is called, and interest is credited to the account. The particular function that is called through the pointer is decided at runtime. That is, it is decided not when the program is compiled but when it executes. Thus, the same function call can do different things depending on what kind of object the pointer points to. Figure 11-5 shows just two different types, but in general, you can get polymorphic behavior with as many different types derived from a common base class as your application requires. You need quite a bit of C++ language know-how to accomplish what we’ve described, and that’s exactly what you’ll be exploring in the rest of this chapter and throughout the next three chapters.

Default Constructors

Hang on a moment! We created a Box object in the previous section and calculated its volume. How could that have happened? There was no constructor defined. Well, there’s no such thing as a class without constructors. If you don’t define a constructor for a class, the compiler will supply a default default constructor . And no, the two “defaults” is no typo. We’ll get back to this shortly. Thanks to this default default constructor, the Box class effectively behaves as if defined as follows:

A default constructor is a constructor that can be called without arguments. If you do not define any constructor for a class—so no default constructor or any other constructor—the compiler generates a default constructor for you. That’s why it’s called a default default constructor; it is a default constructor that is generated by default. A compiler-generated default constructor has no parameters, and its sole purpose is to allow an object to be created. It does nothing else, so the member variables will have their default values. If no initial value is specified for a member variable of either a pointer (int*, const Box* …) or fundamental type (double, int, bool …), it will contain an arbitrary junk value. Note that as soon as you do define any constructor, even a nondefault one with parameters, the default default constructor is no longer supplied. There are circumstances in which you need a constructor with no parameters in addition to a constructor that you define that has parameters. In this case, you must ensure that there is a definition for the no-arg constructor in the class.

Defining a Class Constructor

Let’s extend the Box class from the previous example to incorporate a constructor and then check that it works:

This produces the following output:

The constructor for the Box class has three parameters of type double, corresponding to the initial values for the length, width, and height members of an object. No return type is allowed, and the name of the constructor must be the same as the class name, Box. The first statement in the constructor body outputs a message to show when it’s called. You wouldn’t do this in production programs, but it’s helpful when you’re testing a program and to understand what’s happening and when. We’ll use it regularly to trace what is happening in the examples. The rest of the code in the body of the constructor assigns the arguments to the corresponding member variables. You could include checks that look for valid, non-negative arguments that are the dimensions of a box. In the context of a real application, you’d probably want to do this, but here you only need to learn how a constructor works, so we’ll keep it simple for now.

The firstBox object is created with this statement:

The initial values for the member variables, length, width, and height, appear in the braced initializer and are passed as arguments to the constructor. Because there are three values in the list, the compiler looks for a Box constructor with three parameters. When the constructor is called, it displays the message that appears as the first line of output, so you know that the constructor that you have added to the class is called.

We said earlier that once you define a constructor, the compiler won’t supply a default constructor anymore, at least not by default. That means this statement will no longer compile:

This object would have the default dimensions. If you want to allow Box objects to be defined like this, you must add a definition for a constructor without arguments. We will do so in the next section.

Using the default Keyword

As soon as you add a constructor, any constructor, the compiler no longer implicitly defines a default default constructor . If you then still want your objects to be default-constructible, it is up to you to ensure that the class has a default constructor. Your first option, of course, is to define one yourself. For the Box class of Ex11_01.cpp, for instance, all you’d have to do is add the following constructor definition somewhere in the public section of the class:

Because the member variables of a Box are already given a valid value, 1.0, during their initialization, there is nothing left for you to do in the body of the default constructor.

Instead of defining a default constructor with an empty function body, you can also use the default keyword. This keyword can be used to instruct the compiler to generate a default default constructor, even if there are other user-defined constructors present. For Box, this looks as follows:

Both the equals sign and the semicolon are required. A modified version of Ex11_01 with a defaulted constructor is available online in Ex11_01A.cpp.

While an explicit empty body definition and a defaulted constructor declaration are nearly equivalent, the use of the default keyword is preferred in modern C++ code:

Defining Functions and Constructors Outside the Class

We said earlier that the definition of a member function can be placed outside the class definition. This is also true for class constructors. This can all be done in a single file if you want, but it is far more common to put the class definition in a header file and the definitions of the member functions and constructors in a corresponding source file. We can define the Box class in a header file like this:

The definitions for the volume() member and the constructor then go in a .cpp file. The name of each member function and constructor in the source must be qualified with the class name so the compiler knows to which class they belong:

If Box.h was not included into Box. cpp , the compiler would not know that Box is a class, so the code would not compile. Notice that a constructor that is defaulted using the default keyword in the class definition must not have a definition in the source file.

Separating the definitions of classes from the definitions of their members makes the code easier to manage. For a large class with lots of member functions and constructors, it would be very cumbersome if all the function definitions appeared within the class. More important, any source file that creates objects of type Box just needs to include the header file Box.h. A programmer using this class doesn’t need access to the source code definitions of the member functions, only to the class definition in the header file. As long as the class definition remains fixed, you’re free to change the implementations of the member functions without affecting the operation of programs that use the class.

The previous example would look like this with the Box class split into .h and .cpp files:

This is the same version of main() as in the previous example. The only difference is the #include directive for the Box.h header file that contains the definition of the Box class.

Default Constructor Parameter Values

When we discussed “ordinary” functions, you saw that you can specify default values for the parameters in the function prototype. You can do this for class member functions, including constructors. Default parameter values for constructors and member functions always go inside the class, not in an external constructor or function definition. We can change the class definition in the previous example to the following:

If you make this change to the previous example, what happens? You get an error message from the compiler, of course! The message basically says that you have multiple default constructors defined. The reason for the confusion is the constructor with three parameters allows all three arguments to be omitted, which is indistinguishable from a call to the no-arg constructor. A constructor for which all parameters have a default value still counts as a default constructor. The obvious solution is to get rid of the defaulted constructor that accepts no parameters in this instance. If you do so, everything compiles and executes OK.

Using a Member Initializer List

So far, you’ve set values for member variables in the body of a constructor using explicit assignment. You can use an alternative and more efficient technique that uses a member initializer list. We’ll illustrate this with an alternative version of the Box class constructor :

The values of the member variables are specified as initializing values in the initialization list that is part of the constructor header. length is initialized with lv, for example. The initialization list is separated from the parameter list by a colon (:), and each initializer is separated from the next by a comma (,). If you substitute this version of the constructor in the previous example, you’ll see that it works just as well.

This is more than just a different notation, though. When you initialize a member variable using an assignment statement in the body of the constructor, the member variable is first created (using a constructor call if it is an instance of a class) after which the assignment is carried out as a separate operation. When you use an initialization list, the initial value is used to initialize the member variable as it is created. This can be a much more efficient process, particularly if the member variable is a class instance. This technique for initializing parameters in a constructor is important for another reason. As you’ll see, it is the only way of setting values for certain types of member variables.

There is one small caveat to watch out for. The order in which the member variables are initialized is determined by the order in which they are declared in the class definition—so not as you may expect by the order in which they appear in the member initializer list. This only matters, of course, if the member variables are initialized using expressions for which the order of evaluation matters. Plausible examples would be where a member variable is initialized either by using the value of another one or by calling a member function that relies on other member variables being initialized already. Relying on this evaluation order in production code can be dangerous. Even if everything is working correctly today, next year someone may change the declaration order and inadvertently break the correctness of one of the class’s constructors!

Using the explicit Keyword

A problem with class constructors with a single parameter is that the compiler can use such a constructor as an implicit conversion from the type of the parameter to the class type. This can produce undesirable results in some circumstances. Let’s consider a particular situation. Suppose that you define a class that defines boxes that are cubes for which all three sides have the same length :

You can define the constructor in Cube.cpp as follows:

The definition of the function that calculates the volume will be as follows:

One Cube object is greater than another if its volume is the greater of the two. The hasLargerVolumeThan() member can thus be defined as follows:

The constructor requires only one argument of type double. Clearly, the compiler could use the constructor to convert a double value to a Cube object , but under what circumstances is that likely to happen? The class defines a volume() function and a function to compare the current object with another Cube object passed as an argument, which returns true if the current object has the greater volume. You might use the Cube class in the following way:

Here’s the output:

The output shows that the volume of box1 is definitely not less than 50, but the last line of output indicates the opposite. The code presumes that hasLargerVolumeThan() compares the volume of the current object with 50.0. In reality, the function compares two Cube objects. The compiler knows that the argument to the hasLargerVolumeThan() function should be a Cube object, but it compiles this quite happily because a constructor is available that converts the argument 50.0 to a Cube object. The code the compiler produces is equivalent to the following:

The function is not comparing the volume of the box1 object with 50.0, but with 125000.0, which is the volume of a Cube object with a side of length 50.0! The result is very different from what was expected.

Happily, you can prevent this nightmare from happening by declaring the constructor as explicit:

With this definition for Cube, Ex11_02.cpp will not compile. The compiler never uses a constructor declared as explicit for an implicit conversion; it can be used only explicitly in the program. By using the explicit keyword with constructors that have a single parameter, you prevent implicit conversions from the parameter type to the class type. The hasLargerVolumeThan() member only accepts a Cube object as an argument, so calling it with an argument of type double does not compile.

Delegating Constructors

A class can have several constructors that provide different ways of creating an object. The code for one constructor can call another of the same class in the initialization list. This can avoid repeating the same code in several constructors. Here’s a simple illustration of this using the Box class:

Notice that we have restored the initial values for the member variables and removed the default values for the constructor parameters. This is because the compiler would not be able to distinguish between a call of the constructor with a single parameter and a call of the constructor with three parameters with the last two arguments omitted. This removes the capability for creating an object with no arguments, and the compiler will not supply the default, so we have added the definition of the no-arg constructor to the class.

The implementation of the first constructor can be as follows:

The second constructor creates a Box object with all sides equal, and we can implement it like this:

This constructor just calls the previous constructor in the initialization list. The side argument is used as all three values in the argument list for the previous constructor. This is called a delegating constructor because it delegates the construction work to the other constructor. Delegating constructors help to shorten and simplify constructor code and can make the class definition easier to understand. Here’s an example that exercises this:

The complete code is in the download. The output is as follows:

You can see from the output that creating the first object just calls constructor 1. Creating the second object calls constructor 1 followed by constructor 2. This also shows that execution of the initialization list for a constructor occurs before the code in the body of the constructor. The volumes are as you would expect.

You should only call a constructor for the same class in the initialization list for a constructor. Calling a constructor of the same class in the body of a delegating constructor is not the same. Further, you must not initialize member variables in the initialization list of a delegating constructor. The code will not compile if you do. You can set values for member variables in the body of a delegating constructor, but in that case you should consider whether the constructor should really be implemented as a delegating constructor.

The Copy Constructor

Suppose you add the following statement to main() in Ex11_03.cpp:

The output shows that box3 does indeed have the dimensions of box2, but there’s no constructor defined with a parameter of type Box, so how was box3 created? The answer is that the compiler supplied a default copy constructor, which is a constructor that creates an object by copying an existing object. The default copy constructor copies the values of the member variables of the object that is the argument to the new object.

The default behavior is fine in the case of Box objects , but it can cause problems when one or more member variables are pointers. Just copying a pointer does not duplicate what it points to, which means that when an object is created by the copy constructor, it is interlinked with the original object. Both objects will contain a member pointing to the same thing. A simple example is if an object contains a pointer to a string. A duplicate object will have a member pointing to the same string, so if the string is changed for one object, it will be changed for the other. This is not usually what you want. In this case, you must define a copy constructor. We return to the questions of whether, when, and why to define a copy constructor in Chapter 17. For now, we’ll just focus on the how.

Returning this from a Function

If the return type for a member function is a pointer to the class type, you can return this. You can then use the pointer returned by one member function to call another. Let’s consider an example of where this would be useful.

Suppose you alter the mutator functions of the Box class from Ex11_04 to, after setting the length, width, and height of a box, return a copy of the this pointer:

You can implement these in Box.cpp as follows:

Now you can modify all the dimensions of a Box object in a single statement:

Because the mutator functions return the this pointer, you can use the value returned by one function to call the next. Thus, the pointer returned by setLength() is used to call setWidth(), which returns a pointer you can use to call setHeight(). Isn’t that nice?

Instead of a pointer, you can of course return a reference as well. The setLength() function, for instance, would then become defined as follows:

If you do the same for setWidth() and setHeight(), you obtain the Box class of Ex11_05. The sample program in Ex11_05.cpp then shows that returning references to *this allows you to chain member function calls together as follows:

This pattern is called method chaining. If the goal is to facilitate statements that employ method chaining, it is commonly done using references. You will encounter several conventional examples of this pattern in the next chapter when we discuss operator overloading.

const Member Functions

To see how member functions behave for const objects, let’s go back to the Box class of Ex11_04. In this version of the class, the member variables of a Box object are properly hidden and can be manipulated only through public getter and setter member functions. Suppose now that you change the code in the main() function of Ex11_04 so that myBox is const:

Now the example will no longer compile! Of course, the fact that the compiler refuses to compile the last three lines in the previous code fragment is exactly what you want. After all, you should not be able to alter the state of a const object . We said earlier already the compiler prevents direct assignments to member variables—supposing you have access—so why should it allow indirect assignments inside member functions? The Box object would not be much of an immutable constant if you were allowed to call these setters, now would it?

Unfortunately, however, the getter functions cannot be called on a const object either simply because there’s the risk that they could change the object. In our example, this means that the compiler will not only refuse to compile the last three lines but also the statement before that. Similarly, any attempt to call the volume() member function on a const myBox would result in a compilation error:

Even though you know that volume() doesn’t alter the object, the compiler does not. All it has available when compiling this volume() expression is the function’s prototype in the Box.h header file. And even if it does know the function’s definition from inside the class definition—as with our three getters earlier—the compiler makes no attempt to deduce whether a function modifies the object’s state. All the compiler uses in this setting is the function’s signature.

So, with our current definition of the Box class, const Box objects are rather useless. You cannot call any of its member functions, not even the ones that clearly do not modify any state! To solve this, you’ll have to improve the definition of the Box class. You need a way to tell the compiler which member functions are allowed to be called on const objects. The solutions are so-called const member functions.

First, you need to specify all functions that don’t modify an object as const in the class definition:

Next, you must change the function definition in Box.cpp accordingly:

With these changes, all the calls we expect to work for a const myBox object will effectively work. Of course, calling a setter on it remains impossible. A complete example can be downloaded as Ex11_06.

const Correctness

For const objects you can only call const member functions. The idea is that const objects must be totally immutable, so the compiler will only allow you to call member functions that do not, and never will, modify them. Of course, this only truly makes sense if const member functions effectively cannot modify an object’s state. Suppose you were allowed to write the following:

These three functions clearly modify the state of a Box. So if they were allowed to be declared const like this, you’d again be able to call these setters on const Box objects. This means you would again be able to modify the value of supposedly immutable objects. This would defeat the purpose of const objects. Luckily, the compiler enforces that you can never (inadvertently) modify a const object from inside a const member function. Any attempt to modify an object’s member variable from within a const member functions will result in a compiler error.

Specifying a member function as const effectively makes the this pointer const for that function. The type of the this pointer inside our three setters from before, for instance, would be const Box*, which is pointer to a const Box. And you cannot assign to member variables through a pointer-to-const. Similarly, this implies you cannot call any non-const member functions from within a const member function (because you cannot call non-const member functions on either a pointer-to-const or a reference-to-const). Calling setLength() from within a const volume() member would therefore not be allowed:

Calling const member functions , on the other hand, is allowed:

Since these three getter function are const as well, calling them from within the volume() function is no problem. The compiler knows they will not modify the object either.

The combination of these compiler-enforced restrictions is called const correctness—it prevents const objects from being mutated. We’ll see one final aspect of this at the end of the next subsection.

Overloading on const

Declaring whether a member function is const is part of the function’s signature. This implies that you can overload a non-const member function with a const version. This can be useful and is often done for functions that return a pointer or a reference to (part of) the internal data that is encapsulated by an object. Suppose that instead of the traditional getters and setters for a Box’s member variables, we create functions of this form:

Note that we added underscores to the names of the member variable to avoid them clashing with the names of the member functions. These member functions could now be used as follows:

In a way, these functions are an attempt at a hybrid between a getter and a setter. It’s a failed attempt thus far, because you can currently no longer access the dimensions of a const Box :

You could solve this by overloading the member functions with versions specific for const objects. In general, these extra overloads would have the following form:

Because double is a fundamental type, however, one will often return them by value in these overloads rather than by reference:

Either way, this enables the overloaded length(), width(), and height() functions to be called on const objects as well. Which of the two overloads of each function get used depends on the const-ness of the object upon which the member is called. You could confirm this by adding output statements to both overloads. You can find a little program that does exactly this under Ex11_07.

Note that while it is certainly done at times, in this particular case we do not really recommend using functions of this form to replace the more conventional getter and setters shown earlier. One reason is that statements of the following form are unconventional and hence harder to read or write:

Also, and more important, by adding public member functions that return references to private member variables, you basically forsake most of the advantages of data hiding mentioned earlier in this chapter. You can no longer perform integrity checks on the values assigned to the member variables (such as checking whether all Box dimensions remain positive), change the internal representation of an object, and so on. In other words, it’s almost as bad as simply making the variables public!

There are certainly other circumstances, though, where overloading on const is recommended. You will encounter several examples later, such as when overloading the array access operator in the next chapter.

Casting Away const

Very rarely circumstances can arise where a function is dealing with a const object, either passed as an argument or as the object pointed to by this, and it is necessary to make it non-const. The const_cast<>() operator enables you to do this. The const_cast<>() operator is mostly used in one of the following two forms:

For the first form, the type of expression must be either const Type*; or Type*; for the second, it can be either const Type*, const Type&, Type, or Type&.

Using the mutable Keyword

Ordinarily the member variables of a const object cannot be modified. Sometimes you want to allow particular class members to be modifiable even for a const object. You can do this by specifying such members as mutable. In Ex11_08, for example, we started again from Ex11_06 and added an extra, mutable member variable to the declaration of Box in Box.h as follows:

The mutable keyword indicates that the count member can be changed, even when the object is const. In Box.cpp, we can thus modify the count member in some debugging/logging code inside the newly created printVolume() member function, even though it is declared to be const:

If count would not have been explicitly declared to be mutable, modifying it from within the const printVolume() function would’ve been disallowed by the compiler. Any member function, both const and non-const, can always make changes to member variables specified as mutable.

Note that you should only need mutable member variables in rare cases. Usually, if you need to modify an object from within a const function, it probably shouldn’t have been const. Typical uses of mutable member variables include debugging or logging, caching, and thread synchronization members. The latter two are more advanced, so we won’t be giving any examples of these here.

The Friend Functions of a Class

To make a function a friend of a class, you must declare it as such within the class definition using the friend keyword . It’s the class that determines its friends; there’s no way to make a function a friend of a class from outside the class definition. A friend function can be a global function, or it can be a member of another class. By definition a function can’t be a friend of the class of which it is a member, so access specifiers don’t apply to the friends of a class.

The need for friend functions in practice is limited. They are useful in situations where a function needs access to the internals of two different kinds of objects ; making the function a friend of both classes makes that possible. We will demonstrate how they work in simpler contexts that don’t necessarily reflect a situation where they are required. Suppose that you want to implement a friend function in the Box class to compute the surface area of a Box object. To make the function a friend, you must declare it as such within the Box class definition. Here’s a version that does that:

Box.cpp will contain the definition of the constructor and volume() member. There is nothing in this source file that you haven’t already seen several times before. Here is the code to try the friend function:

Here’s the expected output :

You declare the surfaceArea() function as a friend of the Box class by writing the function prototype within the Box class definition preceded by the friend keyword. The function doesn’t alter the Box object that is passed as the argument, so it’s sensible to use a const reference parameter specification. It’s also a good idea to be consistent when placing the friend declaration within the definition of the class. You can see that we’ve chosen to position this declaration at the end of all the public members of the class. The rationale for this is that the function is part of the class interface because it has full access to all class members.

surfaceArea() is a global function, and its definition follows that of main(). You could put it in Box.cpp because it is related to the Box class, but placing it in the main file helps indicate that it’s a global function.

Notice that you access the member variables of the object within the definition of surfaceArea() by using the Box object that is passed to the function as a parameter. A friend function is not a class member, so the member variables can’t be referenced by their names alone. They each have to be qualified by an object name in the same way as they would be in an ordinary function that accesses public members of a class. A friend function is the same as an ordinary function, except that it can access all the members of a class without restriction.

The main() function creates one Box object by specifying its dimensions; one object with no dimensions specified (so the defaults will apply), and one dynamically allocated Box object. The latter shows that you can create a smart pointer to a Box object allocated in the free store in the way that you have seen with std::string objects. From the output you can see that everything works as expected with all three objects.

Although this example demonstrates how you write a friend function, it is not very realistic. You could have used accessor member functions to return the values of the member variables. Then surfaceArea() wouldn’t need to be a friend function. Perhaps the best option would have been to make surfaceArea() a public member function of the class so that the capability for computing the surface area of a box becomes part of the class interface. A friend function should always be a last resort.

Friend Classes

You can declare a whole class to be a friend of another class. All the member functions of a friend class have unrestricted access to all the members of the class of which it has been declared a friend.

For example, suppose you have defined a Carton class and want to allow the member functions of the Carton class to have access to the members of the Box class. Including a statement in the Box class definition that declares Carton to be a friend will enable this:

Friendship is not a reciprocal arrangement. Functions in the Carton class can access all the members of the Box class, but functions in the Box class have no access to the private members of the Carton class. Friendship among classes is not transitive either; just because class A is a friend of class B and class B is a friend of class C, it doesn’t follow that class A is a friend of class C.

A typical use for a friend class is where the functioning of one class is highly intertwined with that of another. A linked list basically involves two class types: a List class that maintains a list of objects (usually called nodes) and a Node class that defines what a node is. The List class needs to stitch the Node objects together by setting a pointer in each Node object so that it points to the next Node object. Making the List class a friend of the class that defines a node would enable members of the List class to access the members of the Node class directly. Later in this chapter we’ll discuss nested classes, a viable alternative for friend classes in such cases.

Static Member Variables

Static member variables of a class are associated with the class as a whole, not with any particular object of the class. When you declare a member variable of a class as static, the static member variable is defined only once and will exist even if no class objects have been created. Each static member variable is accessible in any object of the class and is shared among however many objects there are. An object gets its own independent copies of the ordinary member variables, but only one instance of each static member variable exists, regardless of how many class objects have been defined.

One use for a static member variable is to count how many objects of a class exist. You could add a static member variable to the Box class by adding the following statement to your class definition:

Figure 11-6 shows how this member exists outside of any objects but is available to all of them.

The static objectCount member is private, so you can’t access objectCount from outside the Box class. Naturally, static members can be either public or protected as well.

The objectCount variable is furthermore specified to be inline to allow its variable definition to be #included in multiple translation units without violating the one definition rule (ODR) . This is analogous to what we explained in the previous chapter for variables at namespace or global scope.

Clearly, inline variables are far more convenient, as they can be initialized in the header file without a separate definition in the source file.

Let’s add the static inline objectCount member variable and the object counting capability to Ex11_10. You need two extra statements in the class definition: one to define the new static member variable and another to declare a function that will retrieve its value.

The getObjectCount() function has been declared as const because it doesn’t modify any of the member variables of the class, and you might want to call it for const or non-const objects.

The constructors in the Box.cpp file need to increment objectCount (except for the constructor that delegates to another Box constructor, of course; otherwise, the count would be incremented twice):

These constructor definitions now update the count when an object is created. You can modify the version of main() from Ex11_10 to output the object count :

This program will produce the same output as before, only this time it will be terminated by the following line:

This code shows that, indeed, only one copy of the static member objectCount exists, and all the constructors are updating it. The getObjectCount() function is called for the box1 object, but you could use any object including any of the array elements to get the same result. Of course, you’re only counting the number of objects that get created. The count that is output corresponds to the number of objects created here. In general, you have no way to know when objects are destroyed yet, so the count won’t necessarily reflect the number of objects that are around at any point. You’ll find out later in this chapter how to account for objects that get destroyed.

Note that the size of a Box object will be unchanged by the addition of objectCount to the class definition. This is because static member variables are not part of any object; they belong to the class. Furthermore, because static member variables are not part of a class object, a const member function can modify non-const static member variables without violating the const nature of the function.

Accessing Static Member Variables

Suppose that in a reckless moment, you declared objectCount as a public class member. You then no longer need the getObjectCount() function to access it. To output the number of objects in main() , just write this:

There’s more. We claimed that a static member variable exists even if no objects have been created. This means that you should be able to get the count before you create the first Box object, but how do you refer to the member variable? The answer is that you use the class name, Box, as a qualifier:

Try it out by modifying the previous example; you’ll see that it works as described. You can always use the class name to access a public static member of a class. It doesn’t matter whether any objects exist. In fact, it is recommended to always use the latter syntax to access static members precisely because this makes it instantly clear when reading the code that it concerns a static member.

Static Constants

Static member variables are often used to define constants . This makes sense. Clearly there’s no point in defining constants as non-static member variables because then an exact copy of this constant would be made for every single object. If you define constants as static members, there is only one single instance of that constant that is shared between all objects.

Prior to C++17, the rules that governed when you could or could not initialize a constant static member variable directly inside a class definition were somewhat complicated (it depended on the type of the variable). Some static constants could be defined in-class, whereas others needed a definition in the corresponding source file. The introduction of inline variables in C++17, however, has made life considerably easier:

Some examples are shown in this definition of a class of cylindrical boxes, which is the latest novelty in the boxing world:

This class defines four inline static constants: maxRadius, maxHeight, defaultMaterial, and PI. Note that, unlike regular member variables, there is no harm in making constants public. In fact, it is quite common to define public constants containing, for instance, boundary values of function parameters (such as maxRadius and maxHeight) or suggested default values (defaultMaterial). Using these, code outside the class can create a narrow, very high CylindricalBox out of its default material as follows:

Inside the body of a member function of the CylindricalBox class, there is no need to qualify the class’s static constant members with the class name:

This function definition uses PI without prepending CylindricalBox::. You’ll find a small test program that exercises this CylindricalBox class in Ex11_12.

Static Member Variables of the Class Type

A static member variable is not part of a class object, so it can be of the same type as the class. The Box class can contain a static member variable of type Box, for example. This might seem a little strange at first, but it can be useful. We’ll use the Box class to illustrate just how. Suppose you need a standard “reference” box for some purpose; you might want to relate Box objects in various ways to a standard box, for example. Of course, you could define a standard Box object outside the class, but if you are going to use it within member functions of the class, it creates an external dependency that it would be better to lose. Suppose we only need it for internal use; then you’d declare this constant as follows:

refBox is const because it is a standard Box object that should not be changed. However, you must still define and initialize it outside the class. You could put a statement in Box.cpp to define refBox:

This calls the Box class constructor to create refBox. Because static member variables of a class are created before any objects are created, at least one Box object will always exist. Any of the static or nonstatic member functions can access refBox. It isn’t accessible from outside the class because it is a private member. A class constant is one situation where you might want to make the member variable public if it has a useful role outside the class. As long as it is declared as const, it can’t be modified.

Static Member Functions

A static member function is independent of any class object. A public static member function can be called even if no class objects have been created. Declaring a static function in a class is easy. You simply use the static keyword as you did with objectCount. You could have declared the getObjectCount() function as static in the previous example. You call a static member function using the class name as a qualifier. Here’s how you could call the static getObjectCount() function :

Of course, if you have created class objects, you can call a static member function through an object of the class in the same way as you call any other member function. Here’s an example:

While the latter is certainly valid syntax, it is not recommended. The reason is that it needlessly obfuscates the fact that it concerns a static member function.

A static member function has no access to the object for which it is called. For a static member function to access an object of the class, it would need to be passed as an argument to the function. Referencing members of a class object from within a static function must then be done using qualified names (as you would with an ordinary global function accessing a public member variable).

A static member function is a full member of the class in terms of access privileges, though. If an object of the same class is passed as an argument to a static member function, it can access private as well as public members of the object. It wouldn’t make sense to do so, but just to illustrate the point, you could include a definition of a static function in the Box class, as shown here:

Even though you are passing the Box object as an argument, the private member variables can be accessed. Of course, it would make more sense to do this with an ordinary member function.

The Truckload Example

We’ll define a class that represents a collection of any number of Box objects. The contents of the header file for the Box class definition will be as follows:

We have omitted the accessor member functions because they are not required here, but we have added a listBox() member to output a Box object. In this case, a Box object represents a unit of a product to be delivered, and a collection of Box objects represents a truckload of boxes, so we’ll call the class Truckload; the collection of Box objects will be a linked list. A linked list can be as long or as short as you need it to be, and you can add objects anywhere in the list. The class will allow a Truckload object to be created from a single Box object or from a vector of Box objects. It will provide for adding and deleting a Box object and for listing all the Box objects in the Truckload.

A Box object has no built-in facility for linking it with another Box object. Changing the definition of the Box class to incorporate this capability would be inconsistent with the idea of a box—boxes aren’t like that. One way to collect Box objects into a list is to define another type of object, which we’ll call Package. A Package object will have two members: a pointer to a Box object and a pointer to another Package object. The latter will allow us to create a chain of Package objects.

Figure 11-7 shows how each Package object points to a Box object—SharedBox will be a type alias for std::shared_ptr<Box>—and also forms a link in a chain of Package objects that are connected by pointers. This chain of Package objects forms a data structure that is known as a linked list. The list can be of unlimited length. As long as you can access the first Package object, you can access the next Package through the pNext pointer it contains, which allows you to reach the next through the pNext pointer that it contains, and so on, through all objects in the list. Each Package object can provide access to the Box object through its pBox member. This arrangement is superior to the Package class having a member that is of type Box, which would require a new Box object to be created for each Package object. The Package class is just a means of tying Box objects together in a linked list, and each Box object should exist independently from the Package objects.

A Truckload object will create and manage a list of Package objects. A Truckload object represents an instance of a truckload of boxes. There can be any number of boxes in a truckload, and each box will be referenced from within a package. A Package object provides the mechanism for the Truckload object to access the pointer to the Box object it contains. Figure 11-8 illustrates the relationship between these objects.

Figure 11-8 shows a Truckload object that manages a list of Package objects; each Package object contains a Box object and a pointer to the next Package object. The Truckload object only needs to keep track of the first Package object in the list; the pHead member contains its address. By following the pNext pointer links, you can find any of the objects in the list. In this elementary implementation, the list can only be traversed from the start. A more sophisticated implementation could provide each Package object with a pointer to the previous object in the list, which would allow the list to be traversed backward as well as forward. Let’s put the ideas into code.

Defining the Truckload Class

A Truckload object will encapsulate a list of Package objects. The class must provide everything necessary to create a new list and to extend the list and delete from it, as well as the means by which Box objects can be retrieved. A pointer to the first Package object in the list as a member variable will allow you to get to any Package object in the list by stepping through the chain of pNext pointers, using the getNext() function from the Package class. The getNext() function will be called repeatedly to step through the list one Package object at a time, so the Truckload object will need to track the object that was retrieved most recently. It’s also useful to store the address of the last Package object because this makes it easy to add a new object to the end of the list. Figure 11-9 shows this.

Consider how retrieving Box objects from a Truckload object could work. This inevitably involves stepping through the list so the starting point is the first object in the list. You could define a getFirstBox() member function in the Truckload class to retrieve the pointer to the first Box object and record the address of the Package object that contained it in pCurrent. You can then implement a getNextBox() member function that will retrieve the pointer to the Box object from the next Package object in the list and then update pCurrent to reflect that. Another essential capability is the ability to add a Box to the list and remove a Box from the list, so you’ll need member functions to do that; addBox() and removeBox() would be suitable names for these. A member function to list all the Box objects in the list will also be handy.

Here’s a definition for the Truckload class based on these ideas:

class Truckload

{

private:

  Package* pHead {};                               // First in the list

  Package* pTail {};                               // Last in the list

  Package* pCurrent {};                            // Last retrieved from the list

public:

  Truckload() = default;                           // Default constructor - empty truckload

  Truckload(SharedBox pBox)                        // Constructor - one Box

  {  pHead = pTail = new Package{pBox}; }

  Truckload(const std::vector<SharedBox>& boxes);  // Constructor - vector of Boxes

  Truckload(const Truckload& src);                 // Copy constructor

  ∼Truckload() { delete pHead; }                   // Destructor: clean up the list

  SharedBox getFirstBox();                         // Get the first Box

  SharedBox getNextBox();                          // Get the next Box

  void addBox(SharedBox pBox);                     // Add a new Box

  bool removeBox(SharedBox pBox);                  // Remove a Box from the Truckload

  void listBoxes() const;                          // Output the Boxes

};

The member variables are private because they don’t need to be accessible outside the class. The getFirstBox() and getNextBox() members provide the mechanism for retrieving Box objects. Each of these needs to modify the pCurrent pointer, so they cannot be const. The addBox() and removeBox() functions also change the list so they cannot be const either.

There are four constructors. The default constructor defines an object containing an empty list. You can also create an object from a single pointer to a Box object, from a vector of pointers, or as a copy of another Truckload. The destructor of the class makes sure the linked list it encapsulates is properly cleaned up. As described earlier, deleting the first Package will trigger all other Packages in the list to be deleted as well.

The constructor that accepts a vector of pointers to Box objects, the copy constructor, and the other member functions of the class require external definitions, which we’ll put in a Truckload.cpp file so they will not be inline. You could define them as inline and include the definitions in Truckload.h.

Adding and Removing Boxes

We’ll start with the easiest of the remaining members: the vector<>-based constructor definition. This creates a list of Package objects from a vector of smart pointers to Box objects:

Truckload::Truckload(const std::vector<SharedBox>& boxes)

{

  for (const auto& pBox : boxes)

  {

    addBox(pBox);

  }

}

The parameter is a reference to avoid copying the argument. The vector elements are of type SharedBox, which is an alias for std::shared_ptr<Box>. The loop iterates through the vector elements passing each one to the addBox() member of the Truckload class, which will create and add a Package object on each call.

The copy constructor simply iterates over all packages in the source Truckload and calls addBox() for each box to add it to the newly constructed Truckload:

Truckload::Truckload(const Truckload& src)

{

  for (Package* package{src.pHead}; package; package = package->getNext())

  {

    addBox(package->getBox());

  }

}

Both of these constructors are made easy because all the heavy lifting is delegated to addBox(). The definition of this member will be as follows:

void Truckload::addBox(SharedBox pBox)

{

  auto pPackage = new Package{pBox};       // Create a new Package

  if (pTail)                               // Check list is not empty

    pTail->setNext(pPackage);              // Append the new object to the tail

  else                                     // List is empty

    pHead = pPackage;                      // so new object is the head

  pTail = pPackage;                        // Either way: the latest object is the (new) tail

}

The function creates a new Package object from the pBox pointer in the free store and stores its address in a local pointer, pPackage. For an empty list, both pHead and pTail will be null. If pTail is non-null, then the list is not empty, and the new object is added to the end of the list by storing its address in the pNext member of the last Package that is pointed to by pTail. If the list is empty, the new Package is the head of the list. In either case, the new Package object is at the end of the list, so pTail is updated to reflect this.

The most complicated of all Truckload member functions is removeBox(). This function also has to traverse the list, looking for the Box to remove. The initial outline of the function is therefore as follows:

bool Truckload::removeBox(SharedBox boxToRemove)

{

  Package* current{pHead};

  while (current)

  {

    if (current->getBox() == boxToRemove)      // We found the Box!

    {

       // remove the *current Package from the linked list...

       return true;                            // Return true: we found and removed the box

    }

    current = current->getNext();              // move along to the next Package

  }

  return false;                                // boxToRemove was not found: return false

}

You know this pattern already from the previous section. Once current points to the Package that needs to be removed, the only challenge remaining is how to correctly remove this Package from the linked list. Figure 11-10 illustrates what needs to be done:

The figure clearly shows that in order to remove a Package somewhere in the middle of the linked list, we need to update the pNext pointer of the previous Package in the list. In Figure 11-10 this is the Package pointed to by previous. This is not yet possible with our initial outline of the function. The current pointer has moved past the Package that needs to be updated, and there is no way to go back.

The standard solution is to keep track of both a previous and a current pointer while traversing the linked list, with previous at all times pointing to the Package that precedes the one pointed to by current. The previous pointer is sometimes called a trailing pointer because it always trails one Package behind the traversal pointer, current. The full function definition looks as follows:

bool Truckload::removeBox(SharedBox boxToRemove)

{

  Package* previous {nullptr};      // no previous yet

  Package* current {pHead};         // initialize current to the head of the list

  while (current)

  {

    if (current->getBox() == boxToRemove)      // We found the Box!

    {

      if (previous)                            // If there is a previous Package...

      {

        previous->setNext(current->getNext()); // ...make it point to the next Package

      }

      else

      {                                        // If there is no previous, we are removing the

        pHead = current->getNext();            // first Package in the list, so update pHead

      }

      current->setNext(nullptr);               // Disconnect the current Package from the list

      delete current;                          // and delete it

      return true;                             // Return true: we found and removed the box

    }

                                               // Move both pointers along (mind the order!)

    previous = current;                        //  - first current becomes the new previous

    current = current->getNext();              //  - then move current along to the next Package

  }

  return false;                                // Return false: boxToRemove was not found

}

Once you know about the trailing pointer technique, putting it all together is not that hard anymore. As always, you have to provide a special case for removing the head of the list, but that’s not too hard. One more thing to watch out for is that the Package that you take out has to be deleted. Before doing that, though, it is important to set its pNext pointer to null first. Otherwise, the destructor of the Package would start deleting the entire list of Packages that used to follow the deleted Package, starting with its pNext.

Nested Classes with Public Access

Of course, you could put the Package class definition in the public section of the TruckLoad class. This would mean that the Package class definition was part of the public interface so it would be possible to create Package objects externally. Because the Package class name is within the scope of the TruckLoad class, you can’t use it by itself. You must qualify the Package class name with the name of the class in which it is nested. Here’s an example:

Of course, making the Package type public in the example would defeat the rationale for making it a nested class in the first place! Of course, there can be other circumstances where a public nested class makes sense. We’ll see one such example in the next subsection.