Discovering Modern C++. An Intensive Course for Scientists, Engineers, and Programmers(2016)

6.1.3.1 Explicit Overriding

Another popular trap that even advanced programmers fall into from time to time is a slightly different signature in the overridden method, like this:

class person
{
virtual void all_info() const { ... }
};

class student
: public person
{
virtual void all_info() { ... }
};

int main ()
{
student tom("Tom Tomson", "Algebra, Analysis");
person& pr= tom;
pr.all_info();
}

In this example, person::all_info() is not lately bound to person::all_info() because the signatures are different. This difference is admittedly not obvious, starting with the question of what the method’s const qualification has to do with the signature at all. We can think of a member function as having an implicit hidden argument referring to the object itself:

void person::all_info_impl(const person& me= *this) { ... }

Now it becomes clear that the const qualifier of the method qualifies this hidden reference in person::all_info(). The corresponding hidden reference in student::all_info() is not const-qualified and the method is not considered as an override due to the distinct signature. The compiler will not warn us, just taking student::all_info() as new overload. And you can believe us that this little nasty mistake can keep you busy for a while, when classes are large and stored in different files.

We can easily protect ourselves against such trouble with the attribute override added to C++11:

class student
: public person
{
virtual void all_info() override { ... }
};

Here the programmer declares that this function overrides a virtual function of the base class (with the exact same signature). If there is no such function, the compiler will complain:¹

1. Messages have been reformatted to fit on the page.

...: error: 'all_info' marked 'override' but doesn't override
any member functions
virtual void all_info() override {
^

...: warning: 'student::all_info' hides overloaded virtual fct.
...: note: hidden overloaded virtual function 'person::all_info'
declared here: different qualifiers (const vs none)
virtual void all_info() const { ... }
^

Here, we also get the hint from clang that the qualifiers are different. Using override for non-virtual functions is an error:

...: error: only virtual member fct. can be marked 'override'
void all_info() override {
^~~~~~~~~

override does not add exciting new functionality to our software, but it can save us from tediously searching for slips of the pen (keyboard). It is advisable to use override everywhere, unless backward compatibility is needed. The word is quickly typed (especially with auto-completion) and renders our programs more reliable. It also communicates our intentions to other programmers or even to ourselves after not having looked at the code for some years.

Another new attribute in C++11 is final. It declares that a virtual member function cannot be overridden. This allows the compiler to replace certain indirect vtable calls with direct function calls. Unfortunately, we have no experience so far with how much final actually accelerates a virtual function. However, we can also use final to protect against surprising behavior of function overriding. Even entire classes can be declared final to prevent somebody from deriving from them.

Compared to each other, override is a statement regarding the super-classes while final refers to sub-classes. Both are contextual keywords; i.e., they are only reserved in a certain context: as qualifiers of member functions. Everywhere else the words could be freely used, for instance, as variable names. However, it is advisable to refrain from doing this for the sake of clarity.

6.1.3.2 Abstract Classes

So far we have looked only at examples where a virtual function was defined in a base class and then expanded in derived classes. Sometimes we find ourselves in a situation where we have an ensemble of classes with a common function and need a common super-class to select the classes dynamically. For instance, in Section 6.4, we will introduce solvers that provide the same interface: a solve function. To select them at run time, they need to share a super-class with a solve function. However, there is no universal solve algorithm that we can override later. For that purpose, we need a new feature to state: “I have a virtual function in this class without implementation; this will come later in sub-classes.”

Definition 6–3 (Pure Virtual Function and Abstract Class). A virtual function is a Pure Virtual Function when it is declared with = 0. A class containing a pure virtual function is called an Abstract Class.

c++11/oop_abstract.cpp

To be more specific, we expand our person example with an abstract super-class creature:

class creature
{
virtual void all_info() const= 0; // pure virtual
};

class person
: public creature
{ ... };

int main ()
{
creature some_beast; // Error: abstract class

person mark("Mark Markson");
mark.all_info();
}

The creation of a creature object fails with a message like this:

...: error: variable type 'creature' is an abstract class
creature some_biest;
^

...: note: unimplemented pure method 'all_info' in 'creature'
virtual void all_info() const= 0;
^

The object mark behaves as before when we override all_info so that person contains no pure virtual functions.

Abstract classes can be considered as interfaces: we can declare references and pointers thereof but no objects. Note that C++ allows us to mix pure and regular virtual functions. Objects of sub-classes can only be built² when all pure virtual functions are overridden.

2. We refrain here from the term Instantiation to avoid confusion. The term is used in Java for saying that an object is built from a class (whereas some authors even call objects specific classes). In C++, instantiation almost always names the process of creating a specific class/function from a class/function template. We have occasionally seen the term “class instantiation” for the creation of an object from a class but this is not common terminology and we refrain from it.

Side note to Java programmers: In Java, all member functions are by nature virtual (i.e., methods cannot be non-virtual³). Java provides the language feature interface where methods are only declared but not defined (unless they have the attribute default which allows for an implementation). This corresponds to a C++ class where all methods are pure virtual.

3. However, declaring them final enables the compiler to remove the overhead of late binding.

Large projects often establish multiple levels of abstraction:

• Interface: no implementations;

• Abstract class: default implementations;

• Specific classes.

This helps to keep a clear mental picture for an elaborate class system.

6.1.4 Functors via Inheritance

In Section 3.8, we discussed functors and mentioned that they can be implemented in terms of inheritance as well. Now, we keep our promise. First we need a common base class for all functors to be realized:

struct functor_base
{
virtual double operator() (double x) const= 0;
};

This base class can be abstract since it only serves us as an interface, for instance, to pass a functor to finite_difference evaluation:

double finite_difference(functor_base const& f,
double x, double h)
{
return (f(x+h) - f(x)) / h;
}

Evidently, all functors to be differentiated must be derived from functor_base, for instance:

class para_sin_plus_cos
: public functor_base
{
public:
para_sin_plus_cos(double p) : alpha(p) {}

virtual double operator() (double x) const override
{
return sin(alpha * x) + cos(x);
}

private:
double alpha;
};

We reimplemented para_sin_plus_cos so that we can approximate the derivative of sin(αx) + cos x with finite differences:

para_sin_plus_cos sin_1 (1.0);
cout finite_difference( sin_1, 1., 0.001 ) endl;
double df1= finite_difference(para_sin_plus_cos(2.), 1., 0.001),
df0= finite_difference(para_sin_plus_cos(2.), 0., 0.001);

The object-oriented approach allows us as well to realize functions with states. If we like, we could also implement the finite differences as OOP functors and combine them similarly as the generic functors.

The disadvantages of the OOP approach are:

• Performance: operator() is always called as a virtual function.

• Applicability: Only classes that are derived from functor_base are allowed as arguments. A template parameter allows for traditional functions and any kind of functors including those from Section 3.8.

Thus, functors should be implemented whenever possible with the generic approach from Section 3.8. Only when functions are selected at run time does the use of inheritance provide a benefit.

6.2 Removing Redundancy

By using inheritance and implicit up-casting, we can avoid the implementation of redundant member and free functions. The fact that classes are implicitly casted to super-classes allows us to implement common functionality once and reuse it in all derived classes. Say we have several matrix classes (dense, compressed, banded, triangle, . . . ) that share member functions like num_rows and num_cols.⁴ Those can be easily outsourced into a common super-class—including the corresponding data members:

4. The terminology used is from MTL4.

class base_matrix
{
public:
base_matrix(size_t nr, size_t nc) : nr(nr), nc(nc) {}
size_t num_rows() const { return nr; }
size_t num_cols() const { return nc; }
private:
size_t nr, nc;
};

class dense_matrix
: public base_matrix
{ ... };

class compressed_matrix
: public base_matrix
{ ... };

class banded_matrix
: public base_matrix
{ ... };

...

All matrix types now provide the member functions from base_matrix by inheritance. Having the common implementations in one place not only saves typing but also ensures that modifications apply in all relevant classes at once. This is not an issue in this toy example (especially as there is not much to change anyway), but keeping all redundant code snippets consistent becomes pretty laborious in large projects.

Free functions can be reused in the same manner, for instance:

inline size_t num_rows(const base_matrix& A)
{ return A.num_rows(); }

inline size_t num_cols(const base_matrix& A)
{ return A.num_cols(); }

inline size_t size(const base_matrix& A)
{ return A.num_rows() * A.num_cols(); }

These free functions can be called for all matrices derived from base_matrix thanks to implicit up-casting. This form of common base class functionality does not cost run time.

We can also consider the implicit up-cast of free functions’ arguments as a special case of a more general concept: the is-a relation; for instance, compressed_matrix is-a base_matrix and we can pass a compressed_matrix value to every function that expects abase_matrix.

6.3 Multiple Inheritance

C++ provides multiple inheritance which we will illustrate now with some examples.

6.3.1 Multiple Parents

c++11/oop_multi0.cpp

A class can be derived from multiple super-classes. For more figurative descriptions and for a less clumsy discussion of base classes’ base classes we occasionally use the terms parents and grandparents which are intuitively understood. With two parents, the class hierarchy looks like a V (and with many like a bouquet). The members of the sub-class are the union of all super-class members. This bears the danger of ambiguities:

class student
{
virtual void all_info() const {
cout "[student] My name is " name endl;
cout " I passed the following grades: " passed endl;
}
...
};

class mathematician
{
virtual void all_info() const {
cout "[mathman] My name is " name endl;
cout " I proved: " proved endl;
}
...
};

class math_student
: public student, public mathematician
{
// all_info not defined -> ambiguously inherited
};

int main ()
{
math_student bob("Robert Robson", "Algebra", "Fermat's Last Theorem");
bob.all_info();
}

math_student inherits all_info from student and from mathematician and there is no priority for one or another. The only way to disambiguate all_info for math_student is to define the method in the class math_student appropriately.

This ambiguity allows us to illustrate a subtlety of C++ that we should be aware of. public, protected, and private modify accessibility, not visibility. This becomes painfully clear when we try to disambiguate member functions by inheriting one or more super-classes asprivate or protected:

class student { ... };
class mathematician { ... };
class math_student
: public student, private mathematician
{ ... };

Now the methods of student are public and those of mathematician private. Calling math_student::all_info we hope to see now the output of student::all_info. Instead we get two error messages: first that math_student::all_info is ambiguous and in addition that mathematician::all_info is inaccessible.

6.3.2 Common Grandparents

It is not rare that multiple base classes share their base classes as well. In the previous section, mathematician and student had no super-classes. From the sections before, it would be more natural to derive them both from person. Depicting this inheritance configuration builds a diamond shape as in Figure 6–2. We will implement this in two slightly different ways.

Figure 6–2: Diamond-shaped class hierarchy

6.3.2.1 Redundancy and Ambiguity

c++11/oop_multi1.cpp

First, we implement the classes in a straightforward way:

class person { ... } // as before
class student { ... } // as before

class mathematician
: public person
{
public:
mathematician(const string& name, const string& proved)
: person(name), proved(proved) {}
virtual void all_info() const override {
person::all_info();
cout " I proved: " proved endl;
}
private:
string proved;
};

class math_student
: public student, public mathematician
{
public:
math_student(const string& name, const string& passed,
const string& proved)
: student(name, passed), mathematician(name, proved) {}
virtual void all_info() const override {
student::all_info();
mathematician::all_info();
}
};

int main ()
{
math_student bob("Robert Robson", "Algebra", "Fermat's Last Theorem");
bob.all_info();
}

The program works properly except for the redundant name information:

[student] My name is Robert Robson
I passed the following grades: Algebra
[person] My name is Robert Robson
I proved: Fermat's Last Theorem

You as reader now have two choices: accept this sub-optimal method and keep reading or jump to Exercise 6.7.1 and try to solve it on your own.

As a consequence of deriving person twice, this code is

• Redundant: The name is stored twice as illustrated in Figure 6–3.

Figure 6–3: Memory layout of math_student

• Error-prone: The two values of name can be inconsistent.

• Ambiguous: when accessing person::name in math_student.

c++11/oop_multi2.cpp

To illustrate the before-mentioned ambiguity, we call person::all_info within math_student:

class math_student : ...
{
virtual void all_info() const override {
person::all_info();
}
};

This causes the following (reformatted) complaint:

...: error: ambiguous conversion from derived class
'const math_student' to base class 'person':
class math_student -> class student -> class person
class math_student -> class mathematician -> class person
person::all_info();
^~~~~~~~~

with clang 3.4. We will of course encounter the same problem with every function or data member of super-classes inherited via multiple paths.

6.3.2.2 Virtual Base Classes

c++11/oop_multi3.cpp

Virtual Base Classes allow us to store members in common super-classes only once and thus help overcome related problems. However, it requires a basic understanding of the internal implementation to not introduce new problems. In the following example, we just denote person as avirtual base class:

class person { ... };

class student
: public virtual person
{ ... };

class mathematician
: public virtual person
{ ... };

class math_student
: public student, public mathematician
{
public:
math_student(const string& name, const string& passed, const string&
proved) : student(name, passed), mathematician(name, proved) {}
...
};

and get the following output that might surprise some of us:

[student] My name is
I passed the following grades: Algebra
I proved: Fermat's Last Theorem

We lost the value of name despite both student and mathematician calling the person constructor which initializes name. To understand this behavior, we need to know how C++ handles virtual base classes. We know that it is a derived class’s responsibility to call the base-class constructor (or else the compiler will generate a call to the default constructor). However, we have only one copy of the person base class. Figure 6–4 illustrates the new memory layout: mathematician and student do not contain the person data any longer but only refer to a common object that is part of the most derived class: math_student.

Figure 6–4: math_student’s memory with virtual base classes

When creating a student object, its constructor must call the person constructor. And likewise when we create a mathematician object, its constructor will call the person constructor. Now we create a math_student object. The math_student constructor must call the constructors of both mathematician and student. But we know that those constructors should both call the person constructor and thus the shared person part would be constructed twice.

To prevent that, it has been defined that in the case of virtual base classes, it is the responsibility of the Most Derived Class (in our case: math_student) to call the shared base-class constructor (in our case: person). In return, the person constructor calls in mathematicianand student are disabled when they are indirectly called from a derived class.

c++11/oop_multi4.cpp

With this in mind, we modify our constructors accordingly:

class student
: public virtual person
{
protected:
student(const string& passed) : passed(passed) {}
...
};

class mathematician
: public virtual person
{
protected:
mathematician(const string& proved) : proved(proved) {}
...
};

class math_student
: public student, public mathematician
{
public:
math_student(const string& name, const string& passed, const string&
proved) : person(name), student(passed), mathematician(proved) {}
virtual void all_info() const override {
student::all_info();
mathematician::my_infos();
}
};

Now, math_student initializes person explicitly to set the name there. The two intermediate classes student and mathematician are refactored to distinguish between inclusive and exclusive member treatment:

• The inclusive handling incorporates the methods from person: the two-argument constructor and all_info. These methods are public and (primarily) intended for student and mathematician objects.

• The exclusive handling deals only with members of the class itself: the one-argument constructor and my_infos. These methods are protected and thus available in sub-classes only.

The example shows that all three access modifiers are needed:

• private: for data members that will only be accessed within the class;

• protected: for methods needed by sub-classes that will not be used for their own objects; and

• public: for methods intended for objects of the class.

After laying the foundations of the OOP techniques, we will apply them now in a scientific context.

6.4 Dynamic Selection by Sub-typing

c++11/solver_selection_example.cpp

The dynamic solver selection can be realized with a switch like this:

#include <iostream>
#include <cstdlib>

class matrix {};
class vector {};

void cg(const matrix& A, const vector& b, vector& x);
void bicg(const matrix& A, const vector& b, vector& x);

int main (int argc, char* argv[])
{
matrix A;
vector b, x;

int solver_choice= argc >= 2 ? std::atoi(argv[1]) : 0;
switch (solver_choice) {
case 0: cg(A, b, x); break;
case 1: bicg(A, b, x); break;
...
}
}

This works but it is not scalable with respect to source code complexity. When we call the solver with other vectors and matrices somewhere else, we must copy the whole switch-case-block for each argument combination. This can be avoided by encapsulating the block into a function and calling this function with different arguments.

The situation becomes much more elaborate when multiple arguments are selected dynamically. For a linear solver, we want to choose the left and right preconditioners (diagonal, ILU, IC, etc.). Then we need nested switch as shown in Section A.8. So we can dynamically select our function objects without OOP, but we have to accept the combinatorial explosion over the parameter space: solvers, left and right preconditioners. If we add a new solver or preconditioner, we will need to expand this monstrous selection block in multiple places.

An elegant solution for our solvers and preconditioners is to use abstract classes as interfaces and derived classes with the specific solvers:

struct solver
{
virtual void operator()( ... )= 0;
virtual ∼solver() {}
};

// potentially templatize
struct cg_solver : solver
{
virtual void operator()( ... ) override { cg(A, b, x); }
};

struct bicg_solver : solver
{
virtual void operator()( ... ) override { bicg(A, b, x); }
};

In our application, we can define a (smart) pointer of the interface type solver and assign it to the desired solver:

unique_ptr<solver> my_solver;
switch (solver_choice) {
case 0: my_solver= unique_ptr<cg_solver>(new cg_solver);
break;
case 1: my_solver= unique_ptr<bicg_solver>(new bicg_solver);
break;
...
}

This technique is thoroughly discussed in the design patterns book [14] as the Factory pattern. The factory can also be implemented with raw pointers in C++03.

The construction of the unique_ptr is somewhat cumbersome. C++14 introduces the convenience function make_unique that makes this situation really more convenient:

unique_ptr<solver> my_solver;
switch (solver_choice) {
case 0: my_solver= make_unique<cg_solver>(); break;
case 1: my_solver= make_unique<bicg_solver>(); break;
}

It is a good exercise to implement your own make_unique as suggested in Exercise 3.11.13.

Once our polymorphic pointer is initialized, it is straightforward to call our dynamically selected solver:

(*my_solver)(A, b, x);

The parentheses here mean that we dereference a function pointer and call the referenced function. Without the parentheses, we would (unsuccessfully) try to call the function pointer as a function and dereference its result.

The full power of the factory approach becomes evident when multiple functions are dynamically selected. Then we can avoid the combinatorial explosion shown before. The polymorphic function pointers allow us to decouple the respective selections and to decompose the task into a sequence of factories and a single call with the pointers:

struct pc
{
virtual void operator()( ... )= 0;
virtual ~pc() {}
};

struct solver { ... };

// Solver factory
// Left Preconditioner factory
// Right Preconditioner factory

(*my_solver)(A, b, x, *left, *right );

Now, we have linear code complexity in the factories and a single statement for the function call opposed to the cubic code complexity in the huge selection block.

In our example, we implemented a common super-class. We can also deal with solver classes and functions without a common base class by using std::function. This allows us to realize more general factories. Nonetheless, it is based on the same techniques: virtual functions and pointers to polymorphic classes. A backward-compatible alternative in C++03 is boost::function.

C++ forbids virtual template functions (they would render the compiler implementation very complicated: potentially infinite vtables). However, class templates can contain virtual functions. This enables generic programming with virtual functions by type parameterization of the entire class instead of parameterizing single methods.

6.5 Conversion

Conversion is a topic not only related to OOP, but we could not discuss it comprehensively without having introduced base and derived classes before. Vice versa, looking at castings between related classes solidifies the understanding of inheritance.

C++ is a strongly typed language. The type of each object (variable or constant) is defined at compile time and cannot be changed during execution.⁵ We can think of an object as

5. In contrast, Python variables have no fixed type and are actually merely names referring to some object. In an assignment, the variable just refers to another object and adopts the new object’s type.

• Bits in memory, and

• A type that gives those bits a meaning.

For several casts, the compiler just looks differently on the bits in memory: either with another interpretation of the bits or with other access rights (e.g., const versus non-const). Other casts actually create new objects.

In C++, there are four different cast operators:

• static_cast

• dynamic_cast

• const_cast

• reinterpret_cast

C as its linguistic root knows only one casting operator: ( type ) expr. This single operator is difficult to understand because it can trigger a cascade of transformations to create an object of the target type: for instance, converting a const pointer to int into a non-const pointer to char.

In contrast, the C++ casts only change one aspect of the type at a time. Another disadvantage of C-style casts is that they are hard to find in code (see also [45, Chapter 95]), whereas the C++ casts are easy to discover: just search for _cast. C++ still allows this old-style casting but all C++ experts agree on discouraging its use.