…Write a Class

Don’t remember how to get started? No problem—here is the definition of a simple class:

#pragma once

// A simple class that illustrates class definition syntax.
class Simple
{
    public:
        Simple();                       // Constructor
        virtual ~Simple() = default;    // Defaulted virtual destructor

        // Disallow assignment and pass-by-value.
        Simple(const Simple& src) = delete;
        Simple& operator=(const Simple& rhs) = delete;

        // Explicitly default move constructor and move assignment operator.
        Simple(Simple&& src) = default;
        Simple& operator=(Simple&& rhs) = default;

        virtual void publicMethod();    // Public method
        int mPublicInteger;             // Public data member

    protected:
        virtual void protectedMethod(); // Protected method
        int mProtectedInteger = 41;     // Protected data member

    private:
        virtual void privateMethod();   // Private method
        int mPrivateInteger = 42;       // Private data member
        static const int kConstant = 2; // Private constant
        static int sStaticInt;          // Private static data member
};

As Chapter 10 explains, it’s a good idea to always make at least your destructor virtual in case someone wants to derive from your class. It’s allowed to leave the destructor non-virtual, but only if you mark your class as final so that no other classes can derive from it. If you only want to make your destructor virtual but you don’t need any code inside the destructor, then you can explicitly default it, as in the Simple class example.

This example also demonstrates that you can explicitly delete or default special member functions. The copy constructor and copy assignment operator are deleted to prevent assignment and pass-by-value, while the move constructor and move assignment operator are explicitly defaulted.

Next, here is the implementation, including the initialization of the static data member:

#include "Simple.h"

int Simple::sStaticInt = 0;   // Initialize static data member.

Simple::Simple() : mPublicInteger(40)
{
    // Implementation of constructor
}

void Simple::publicMethod() { /* Implementation of public method */ }

void Simple::protectedMethod() { /* Implementation of protected method */ }

void Simple::privateMethod() { /* Implementation of private method */ }

With C++17, you can remove the initialization of sStaticInt from the source file if you make it an inline variable instead, initialized in the class definition as follows:

static inline int sStaticInt = 0;          // Private static data member

Chapters 8 and 9 provide all the details for writing your own classes.

…Derive from an Existing Class

To derive from an existing class, you declare a new class that is an extension of another class. Here is the definition for a class called DerivedSimple, which derives from Simple:

#pragma once

#include "Simple.h"

// A derived class of the Simple class.
class DerivedSimple : public Simple
{
    public:
        DerivedSimple();                      // Constructor

        virtual void publicMethod() override; // Overridden method
        virtual void anotherMethod();         // Added method
};

The implementation is as follows:

#include "DerivedSimple.h"

DerivedSimple::DerivedSimple() : Simple()
{
    // Implementation of constructor
}

void DerivedSimple::publicMethod()
{
    // Implementation of overridden method
    Simple::publicMethod(); // You can access base class implementations.
}

void DerivedSimple::anotherMethod()
{
    // Implementation of added method
}

Consult Chapter 10 for details on inheritance techniques.

…Use the Copy-and-Swap Idiom

The copy-and-swap idiom is discussed in detail in Chapter 9. It’s an idiom to implement a possibly throwing operation on an object with a strong exception-safety guarantee, that is, all-or-nothing. You simply create a copy of the object, modify that copy (can be a complex algorithm, possibly throwing exceptions), and finally, when no exceptions have been thrown, swap the copy with the original object. An assignment operator is an example of an operation for which you can use the copy-and-swap idiom. Your assignment operator first makes a local copy of the source object, then swaps this copy with the current object using only a non-throwing swap() implementation.

Here is a concise example of the copy-and-swap idiom used for a copy assignment operator. The class defines a copy constructor, a copy assignment operator, and a friend swap() function, which is marked as noexcept.

class CopyAndSwap
{
    public:
        CopyAndSwap() = default;
        virtual ~CopyAndSwap();                         // Virtual destructor

        CopyAndSwap(const CopyAndSwap& src);            // Copy constructor
        CopyAndSwap& operator=(const CopyAndSwap& rhs); // Assignment operator

        friend void swap(CopyAndSwap& first, CopyAndSwap& second) noexcept;

    private:
        // Private data members…
};

The implementation is as follows:

CopyAndSwap::~CopyAndSwap()
{
    // Implementation of destructor
}

CopyAndSwap::CopyAndSwap(const CopyAndSwap& src)
{
    // This copy constructor can first delegate to a non-copy constructor
    // if any resource allocations have to be done. See the Spreadsheet
    // implementation in Chapter 9 for an example.

    // Make a copy of all data members
}

void swap(CopyAndSwap& first, CopyAndSwap& second) noexcept
{
    using std::swap;  // Requires <utility>

    // Swap each data member, for example:
    // swap(first.mData, second.mData);
}

CopyAndSwap& CopyAndSwap::operator=(const CopyAndSwap& rhs)
{
    // Check for self-assignment
    if (this == &rhs) {
        return *this;
    }

    auto copy(rhs);     // Do all the work in a temporary instance
    swap(*this, copy);  // Commit the work with only non-throwing operations
    return *this;
}

Consult Chapter 9 for a more detailed discussion.

…Throw and Catch Exceptions

If you’ve been working on a team that doesn’t use exceptions (for shame!) or if you’ve gotten used to Java-style exceptions, the C++ syntax may escape you. Here’s a refresher that uses the built-in exception class std::runtime_error. In most large programs, you will write your own exception classes.

#include <stdexcept>
#include <iostream>

void throwIf(bool throwIt)
{
    if (throwIt) {
        throw std::runtime_error("Here's my exception");
    }
}

int main()
{
    try {
        throwIf(false); // doesn't throw
        throwIf(true);  // throws
    } catch (const std::runtime_error& e) {
        std::cerr << "Caught exception: " << e.what() << std::endl;
        return 1;
    }
    return 0;
}

Chapter 14 discusses exceptions in more detail.

…Read from a File

Complete details for file input are included in Chapter 13. Here is a quick sample program for file reading basics. This program reads its own source code and outputs it one token at a time:

#include <iostream>
#include <fstream>
#include <string>

using namespace std;

int main()
{
    ifstream inputFile("FileRead.cpp");
    if (inputFile.fail()) {
        cerr << "Unable to open file for reading." << endl;
        return 1;
    }

    string nextToken;
    while (inputFile >> nextToken) {
        cout << "Token: " << nextToken << endl;
    }
    return 0;
}

…Write to a File

The following program outputs a message to a file, then reopens the file and appends another message. Additional details can be found in Chapter 13.

#include <iostream>
#include <fstream>

using namespace std;

int main()
{
    ofstream outputFile("FileWrite.out");
    if (outputFile.fail()) {
        cerr << "Unable to open file for writing." << endl;
        return 1;
    }
    outputFile << "Hello!" << endl;
    outputFile.close();

    ofstream appendFile("FileWrite.out", ios_base::app);
    if (appendFile.fail()) {
        cerr << "Unable to open file for appending." << endl;
        return 2;
    }
    appendFile << "Append!" << endl;
    return 0;
}

…Write a Template Class

Template syntax is one of the messiest parts of the C++ language. The most-forgotten piece of the template puzzle is that code that uses a class template needs to be able to see the method implementations as well as the class template definition. The same holds for function templates. For class templates, the usual technique to accomplish this is to simply put the implementations directly in the header file following the class template definition, as in the following example. Another technique is to put the implementations in a separate file, often with an .inl extension, and then #include that file as the last line in the class template header file. The following program shows a class template that wraps a reference to an object and adds get and set semantics to it. Here is the SimpleTemplate.h header file:

template <typename T>
class SimpleTemplate
{
    public:
        SimpleTemplate(T& object);

        const T& get() const;
        void set(const T& object);
    private:
        T& mObject;
};

template<typename T>
SimpleTemplate<T>::SimpleTemplate(T& object) : mObject(object)
{
}

template<typename T>
const T& SimpleTemplate<T>::get() const
{
    return mObject;
}

template<typename T>
void SimpleTemplate<T>::set(const T& object)
{
    mObject = object;
}

The code can be tested as follows:

#include <iostream>
#include <string>
#include "SimpleTemplate.h"

using namespace std;

int main()
{
    // Try wrapping an integer.
    int i = 7;
    SimpleTemplate<int> intWrapper(i);
    i = 2;
    cout << "wrapped value is " << intWrapper.get() << endl;

    // Try wrapping a string.
    string str = "test";
    SimpleTemplate<string> stringWrapper(str);
    str += "!";
    cout << "wrapped value is " << stringWrapper.get() << endl;
    return 0;
}

Details about templates can be found in Chapters 12 and 22.

Resource Acquisition Is Initialization

RAII, or Resource Acquisition Is Initialization, is a simple yet very powerful concept. It is used to automatically free acquired resources when an RAII instance goes out of scope. This happens at a deterministic point in time. Basically, the constructor of a new RAII instance acquires ownership of a certain resource and initializes the instance with that resource, hence the name Resource Acquisition Is Initialization. The destructor automatically frees the acquired resource when the RAII instance is destroyed.

Here is an example of a File RAII class that safely wraps a C-style file handle (std::FILE) and automatically closes the file when the RAII instance goes out of scope. The RAII class also provides get(), release(), and reset() methods that behave similar to the same methods on certain Standard Library classes, such as std::unique_ptr.

#include <cstdio>

class File final
{
    public:
        File(std::FILE* file);
        ~File();

        // Prevent copy construction and copy assignment.
        File(const File& src) = delete;
        File& operator=(const File& rhs) = delete;

        // Allow move construction and move assignment.
        File(File&& src) noexcept = default;
        File& operator=(File&& rhs) noexcept = default;

        // get(), release(), and reset()
        std::FILE* get() const noexcept;
        std::FILE* release() noexcept;
        void reset(std::FILE* file = nullptr) noexcept;

    private:
        std::FILE* mFile;
};

File::File(std::FILE* file) : mFile(file)
{
}

File::~File()
{
    reset();
}

std::FILE* File::get() const noexcept
{
    return mFile;
}

std::FILE* File::release() noexcept
{
    std::FILE* file = mFile;
    mFile = nullptr;
    return file;
}

void File::reset(std::FILE* file /*= nullptr*/) noexcept
{
    if (mFile) {
        fclose(mFile);
    }
    mFile = file;
}

It can be used as follows:

File myFile(fopen("input.txt", "r"));

As soon as the myFile instance goes out of scope, its destructor is called, and the file is automatically closed.

I recommend to never include a default constructor or to explicitly delete the default constructor for RAII classes. The reason can best be explained using a Standard Library RAII class that has a default constructor, std::unique_lock (see Chapter 23). Proper use of unique_lock is as follows:

class Foo
{
    public:
        void setData();
    private:
        mutex mMutex;
};

void Foo::setData()
{
    unique_lock<mutex> lock(mMutex);
    // …
}

The setData() method uses the unique_lock RAII object to construct a local lock object that locks the mMutex data member and automatically unlocks that mutex at the end of the method.

However, because you do not directly use the lock variable after it has been defined, it is easy to make the following mistake:

void Foo::setData()
{
    unique_lock<mutex>(mMutex);
    // …
}

In this code, you accidentally forgot to give the unique_lock a name. This will compile, but it does not what you intended it to do! It will actually declare a local variable called mMutex (hiding the mMutex data member), and initialize it with a call to the unique_lock’s default constructor. The result is that the mMutex data member is not locked!

Double Dispatch

Double dispatch is a technique that adds an extra dimension to the concept of polymorphism. As described in Chapter 5, polymorphism lets the program determine behavior based on types at run time. For example, you could have an Animal class with a move() method. All Animals move, but they differ in terms of how they move. The move() method is defined for every derived class of Animal so that the appropriate method can be called, or dispatched, for the appropriate animal at run time without knowing the type of the animal at compile time. Chapter 10 explains how to use virtual methods to implement this run-time polymorphism.

Sometimes, however, you need a method to behave according to the run-time type of two objects, instead of just one. For example, suppose that you want to add a method to the Animal class that returns true if the animal eats another animal, and false otherwise. The decision is based on two factors: the type of animal doing the eating, and the type of animal being eaten. Unfortunately, C++ provides no language mechanism to choose a behavior based on the run-time type of more than one object. Virtual methods alone are insufficient for modeling this scenario because they determine a method, or behavior, depending on the run-time type of only the receiving object.

Some object-oriented languages provide the ability to choose a method at run time based on the run-time types of two or more objects. They call this feature multi-methods. In C++, however, there is no core language feature to support multi-methods, but you can use the double dispatch technique, which provides a way to make functions virtual for more than one object.

class Animal
{
    public:
        virtual bool eats(const Animal& prey) const = 0;
};

bool Bear::eats(const Animal& prey) const
{
    if (typeid(prey) == typeid(Bear)) {
        return false;
    } else if (typeid(prey) == typeid(Fish)) {
        return true;
    } else if (typeid(prey) == typeid(Dinosaur)) {
        return false;
    }
    return false;
}

bool Fish::eats(const Animal& prey) const
{
    if (typeid(prey) == typeid(Bear)) {
        return false;
    } else if (typeid(prey) == typeid(Fish)) {
        return true;
    } else if (typeid(prey) == typeid(Dinosaur)) {
        return false;
    }
    return false;
}

bool Dinosaur::eats(const Animal& prey) const
{
    return true;
}

class Animal
{
    public:
        virtual bool eats(const Bear&) const = 0;
        virtual bool eats(const Fish&) const = 0;
        virtual bool eats(const Dinosaur&) const = 0;
};

class Bear : public Animal
{
    public:
        virtual bool eats(const Bear&) const override { return false; }
        virtual bool eats(const Fish&) const override { return true; }
        virtual bool eats(const Dinosaur&) const override { return false; }
};

Bear myBear;
Fish myFish;
cout << myBear.eats(myFish) << endl;

Bear myBear;
Fish myFish;
Animal& animalRef = myBear;
cout << animalRef.eats(myFish) << endl;

Bear myBear;
Fish myFish;
Animal& animalRef = myFish;
cout << myBear.eats(animalRef) << endl; // BUG! No method Bear::eats(Animal&)

virtual bool eats(const Animal& prey) const override;

bool Bear::eats(const Animal& prey) const
{
    return prey.eatenBy(*this);
}

// forward declarations
class Fish;
class Bear;
class Dinosaur;

class Animal
{
    public:
        virtual bool eats(const Animal& prey) const = 0;

        virtual bool eatenBy(const Bear&) const = 0;
        virtual bool eatenBy(const Fish&) const = 0;
        virtual bool eatenBy(const Dinosaur&) const = 0;
};

class Bear : public Animal
{
    public:
        virtual bool eats(const Animal& prey) const override;

        virtual bool eatenBy(const Bear&) const override;
        virtual bool eatenBy(const Fish&) const override;
        virtual bool eatenBy(const Dinosaur&) const override;
};
// The definitions for the Fish and Dinosaur classes are identical to the
// Bear class, so they are not shown here.

bool Bear::eats(const Animal& prey) const { return prey.eatenBy(*this); }
bool Bear::eatenBy(const Bear&) const { return false; }
bool Bear::eatenBy(const Fish&) const { return false; }
bool Bear::eatenBy(const Dinosaur&) const { return true; }

bool Fish::eats(const Animal& prey) const { return prey.eatenBy(*this); }
bool Fish::eatenBy(const Bear&) const { return true; }
bool Fish::eatenBy(const Fish&) const { return true; }
bool Fish::eatenBy(const Dinosaur&) const { return true; }

bool Dinosaur::eats(const Animal& prey) const { return prey.eatenBy(*this); }
bool Dinosaur::eatenBy(const Bear&) const { return false; }
bool Dinosaur::eatenBy(const Fish&) const { return false; }
bool Dinosaur::eatenBy(const Dinosaur&) const { return true; }

Mixin Classes

Chapters 5 and 10 introduce the technique of using multiple inheritance to build mixin classes. Mixin classes add a small piece of extra behavior to a class in an existing hierarchy. You can usually spot a mixin class by its name, which ends in “-able”, for example, Clickable, Drawable, Printable, or Lovable.

Designing a Mixin Class

Mixin classes contain actual code that can be reused by other classes. A single mixin class implements a well-defined piece of functionality. For example, you might have a mixin class called Playable that is mixed into certain types of media objects. The mixin class could, for example, contain most of the code to communicate with the computer’s sound drivers. By mixing in the class, the media object would get that functionality for free.

When designing a mixin class, you need to consider what behavior you are adding and whether it belongs in the object hierarchy or in a separate class. Using the previous example, if all media classes are playable, the base class should derive from Playable instead of mixing the Playable class into all of the derived classes. If only certain media classes are playable and they are scattered throughout the hierarchy, a mixin class makes sense.

One of the cases where mixin classes are particularly useful is when you have classes organized into a hierarchy on one axis, but they also contain similarities on another axis. For example, consider a war simulation game played on a grid. Each grid location can contain an Item with attack and defense capabilities and other characteristics. Some items, such as a Castle, are stationary. Others, such as a Knight or FloatingCastle, can move throughout the grid. When initially designing the object hierarchy, you might end up with something like Figure 28-1, which organizes the classes according to their attack and defense capabilities.

The hierarchy in Figure 28-1 ignores the movement functionality that certain classes contain. Building your hierarchy around movement would result in a structure similar to Figure 28-2.

Of course, the design of Figure 28-2 throws away all the organization of Figure 28-1. What’s a good object-oriented programmer to do?

There are two common solutions for this problem. Assuming that you go with the first hierarchy, organized around attackers and defenders, you need some way to work movement into the equation. One possibility is that, even though only a portion of the derived classes support movement, you could add a move() method to the Item base class. The default implementation would do nothing. Certain derived classes would override move() to actually change their location on the grid.

The other approach is to write a Movable mixin class. The elegant hierarchy from Figure 28-1 could be preserved, but certain classes in the hierarchy would derive from Movable in addition to their parent. Figure 28-3 shows this design.

class Movable
{
    public:
        virtual void move() { /* Implementation to move an item… */ }
};

class FloatingCastle : public Castle, public Movable
{
    // …
};

Working with Frameworks

The defining characteristic of a framework is that it provides its own set of techniques and patterns. Frameworks usually require a bit of learning to get started with because they have their own mental model. Before you can work with a large application framework, such as the Microsoft Foundation Classes (MFC), you need to understand its view of the world.

Frameworks vary greatly in their abstract ideas and in their actual implementation. Many frameworks are built on top of legacy procedural APIs, which may affect various aspects of their design. Other frameworks are written from the ground up with object-oriented design in mind. Some frameworks might ideologically oppose certain aspects of the C++ language. For example, a framework could consciously shun the notion of multiple inheritance.

When you start working with a new framework, your first task is to find out what makes it tick. To what design principles does it subscribe? What mental model are its developers trying to convey? What aspects of the language does it use extensively? These are all vital questions, even though they may sound like things that you’ll pick up along the way. If you fail to understand the design, model, or language features of the framework, you will quickly get into situations where you overstep the bounds of the framework.

An understanding of the framework’s design will also make it possible for you to extend it. For example, if the framework omits a feature, such as support for printing, you could write your own printing classes using the same model as the framework. By doing so, you retain a consistent model for your application, and you have code that can be reused by other applications.

A framework might use certain specific data types. For example, the MFC framework uses the CString data type to represent strings, instead of using the Standard Library std::string class. This does not mean that you have to switch to the data types provided by the framework for your entire code base. Instead, you should convert the data types on the boundaries between the framework code and the rest of your code.

The Model-View-Controller Paradigm

As I mentioned earlier, frameworks vary in their approaches to object-oriented design. One common paradigm is known as model-view-controller, or MVC. This paradigm models the notion that many applications commonly deal with a set of data, one or more views on that data, and manipulation of the data.

In MVC, a set of data is called the model. In a race car simulator, the model would keep track of various statistics, such as the current speed of the car and the amount of damage it has sustained. In practice, the model often takes the form of a class with many getters and setters. The class definition for the model of the race car might look as follows:

class RaceCar
{
    public:
        RaceCar();
        virtual ~RaceCar() = default;

        virtual double getSpeed() const;
        virtual void setSpeed(double speed);

        virtual double getDamageLevel() const;
        virtual void setDamageLevel(double damage);
    private:
        double mSpeed;
        double mDamageLevel;
};

A view is a particular visualization of the model. For example, there could be two views on a RaceCar. The first view could be a graphical view of the car, and the second could be a graph that shows the level of damage over time. The important point is that both views are operating on the same data—they are different ways of looking at the same information. This is one of the main advantages of the MVC paradigm: by keeping data separated from its display, you can keep your code more organized, and easily create additional views.

The final piece to the MVC paradigm is the controller. The controller is the piece of code that changes the model in response to some event. For example, when the driver of the race car simulator runs into a concrete barrier, the controller instructs the model to bump up the car’s damage level and reduce its speed. The controller can also manipulate the view. For example, when the user scrolls a scrollbar in the user interface, the controller instructs the view to scroll its content.

The three components of MVC interact in a feedback loop. Actions are handled by the controller, which adjusts the model and/or views. If the model changes, it notifies the views to update them. This interaction is shown in Figure 28-4.

The model-view-controller paradigm has gained widespread support within many popular frameworks. Even nontraditional applications, such as web applications, are moving in the direction of MVC because it enforces a clear separation between data, the manipulation of data, and the displaying of data.

The MVC pattern has evolved into several different variants, such as model-view-presenter (MVP), model-view-adapter (MVA), model-view-viewmodel (MVVM), and so on.