Chapter 9 Design Patterns and Idioms

The Copy-and-Swap Idiom

In the section “Prevention Is Better Than Aftercare” in Chapter 5, we learned the four levels of exception-safety guarantee: no exception-safety, basic exception-safety, strong exception-safety, and the no-throw guarantee. What member functions of a class should always guarantee is the basic exception-safety, because this exception-safety level is usually easy to implement.

In the section “The Rule of Zero” in Chapter 5, we learned that we should design classes in a way that the compiler-generated special member functions (copy constructor, copy assignment operator, etc.) automatically do the right things. Or in other words, when we are forced to provide a non-trivial destructor, we are dealing with an exceptional case that requires special treatment during destruction of the object. As a consequence, it follows that the special member functions generated by the compiler are not sufficient to deal with this situation, and we have to implement them by ourselves.

However, it is inevitable that the Rule of Zero will occasionally not be fulfilled, that is, a developer has to implement the special member functions by herself. In this case, it may be a challenging task to create an exception-safe implementation of an overloaded assignment operator. In such a case, the Copy-and-Swap idiom is an elegant way to solve this problem.

Hence, the intent of this idiom is as follows:

“Implement the copy assignment operator with strong exception safety.”

The simplest way to explain the problem and its solution is with a small example. Consider the class shown in Listing 9-47.

Listing 9-47.  A Class That Manages a Resource That Is Allocated on the Heap

#include <cstddef>

class Clazz final { public:

explicit Clazz(const std::size_t size) : resourceToManage { new char[size] }, size { size } { }

~Clazz() {

delete [] resourceToManage;

}

443

Chapter 9 Design Patterns and Idioms

private:

char* resourceToManage; std::size_t size;

};

This class is, of course, only for demonstration purposes and should not be part of a real program.

Let’s assume that we want to do the following with the class Clazz:

int main() {

Clazz instance1 { 1000 }; Clazz instance2 { instance1 }; return 0;

}

We know from Chapter 5 that the compiler-generated version of a copy constructor does the wrong thing here: it only creates a flat copy of the character pointer resourceToManage!

Hence, we have to provide our own copy constructor, like so:

#include <algorithm>

class Clazz final { public:

// ...

Clazz(const Clazz& other) : Clazz { other.size } { std::copy(other.resourceToManage, other.resourceToManage + other.size, resourceToManage);

}

// ...

};

So far, so good. Now the copy construction will work fine. But now we’ll also need a copy assignment operator. If you are not familiar with the copy-and-swap idiom, an implementation of an assignment operator might look like this:

#include <algorithm>

class Clazz final {

444

Chapter 9 Design Patterns and Idioms

public: // ...

Clazz& operator=(const Clazz& other) { if (&other == this) {

return *this;

}

delete [] resourceToManage; resourceToManage = new char[other.size];

std::copy(other.resourceToManage, other.resourceToManage + other.size, resourceToManage);

size = other.size; return *this;

}

// ...

};

Basically, this assignment operator will work, but it has several drawbacks. For instance, the constructor and destructor code is duplicated in it, which is a violation of the DRY principle (see Chapter 3). Furthermore, there is a self-assignment check at the beginning. But the biggest disadvantage is that we cannot guarantee exception-safety. For example, if the new statement causes an exception, the object can be left behind in a weird state that violates elementary class invariants.

Now the copy-and-swap idiom comes into play, also known as “Create-Temporary-­ and-Swap”!

For a better understanding, I present the whole class Clazz in Listing 9-48.

Listing 9-48.  A Much Better Implementation of an Assignment Operator Using the Copy-and-Swap Idiom

#include <algorithm> #include <cstddef>

class Clazz final { public:

explicit Clazz(const std::size_t size) : resourceToManage { new char[size] },

size { size } { }

445

Chapter 9 Design Patterns and Idioms

~Clazz() {

delete [] resourceToManage;

}

Clazz(const Clazz& other) : Clazz { other.size } { std::copy(other.resourceToManage, other.resourceToManage + other.size,

resourceToManage);

}

Clazz& operator=(Clazz other) { swap(other);

return *this;

}

private:

void swap(Clazz& other) noexcept { using std::swap;

swap(resourceToManage, other.resourceToManage); swap(size, other.size);

}

char* resourceToManage{ nullptr }; std::size_t size{ 0 };

};

What is the trick here? Let’s look at the completely different assignment operator. This no longer has a const reference (const Clazz& other) as a parameter, but an ordinary value parameter (Clazz other). This means that when this assignment operator is called, the copy constructor of Clazz is called. The copy constructor, in turn, calls the default constructor that allocates memory for the resource. And that is exactly what we want: we need a temporary copy of other!

Now we come to the heart of the idiom: the call of the private member function Clazz::swap(). Within this function, the contents of the temporary instance other, that is, its member variables, are exchanged (“swapped”) with the contents of the same member variables of our own class context (this). This is done by using the non-throwing std::swap() function (defined in the <utility> header). After the swap operations, the temporary object called other now owns the resources that were previously owned by the this object, and vice versa.

446