Copy Control

A class controls what happens when objects of class type are copied, moved, assigned, and destroyed by defining five special member functions: copy constructor, move constructor, copy-assignment operator, move-assignment operator, destructor. The copy and move constructors define what happens when an object is initialized from another object of the same type. The copy and move assignment operators define what happens when we assign an object of a class type to another object of that same class type. The destructor defines what happens when an object ceases to exist. If a class does not define all of the copy-control members, the compiler automatically defines the missing operations.

The Copy Constructor

A constructor is the copy constructor if its first parameter is a reference to the class type and any additional parameters have default values. The first parameter must be a reference type, and it is almost always a reference to const, although we can define a reference to nonconst. Unlike the synthesized default constructor, a copy constructor is synthesized even if we define other constructors.

1
2
3
4
5

class Foo {
public:
    Foo();              // default constructor
    Foo(const Foo&);    // copy constructor
};

The Synthesized Copy Constructor

The type of each member determines how that member is copied: Members of class type are copied by the copy constructor for that class; members of built-in type are copied directly. Although we cannot directly copy an array, the synthesized copy constructor copies members of array type by copying each element. Elements of class type are copied by using the element’s copy constructor. For example, the synthesized copy constructor:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

class Sales_data {
public:
    Sales_data(const Sales_data &orig);
private:
    string bookNo;
    int units_sold = 0;
    double revenue = 0.0;
};

Sales_data::Sales_data(const Sales_data &orig):
    bookNo(orig.bookNo), // use the string copy constructor
    units_sold(orig.units_sold),
    revenue(orig.revenue)
{
}

Copy Initialization

We are now in a position to fully understand the differences between direct initialization and copy initialization:

1
2
3
4
5

string dots(10, '.');                // direct initialization
string s(dots);                      // direct initialization
string s2 = dots;                    // copy initialization
string null_book = "9-999-99999-9";  // copy initialization
string nines = string(100, '9');     // copy initialization

When using direct initialization, we are asking the compiler to use ordinary function matching to select the constructor that best matches the arguments we provide. When we use copy initialization, we are asking the compiler to copy the right-hand operand into the object being created, converting that operand if necessary.

Copy initialization ordinary uses the copy constructor. However, if a class has a move constructor, then copy initialization sometimes uses the move constructor instead of the copy constructor. Copy initialization happens not only when we define variables using an =, but also when we

• pass an object as an argument to a parameter of nonreference type
• return an object from a function that has a nonreference return type
• brace initialization the elements in an array or the members of an aggregate class

Some class types also use copy initialization for the objects they allocate. For example, the library containers copy initialize their elements when we initialize the container, or when we call an insert or push member. By contrast, elements created by an emplace member are direct initialized.

During a function call, parameters that have a nonreference type are copy initialized. This explains why the copy constructor’s own parameters must be a reference. If that parameter were not a reference, then the call would never succeed.

Whether we use copy or direct initialization matters if we use an initializer that requires conversion by an explicit constructors:

1
2
3
4
5

vector<int> v1(10);  // ok: direct initialization
vector<int> v2 = 10; // error: constructor that takes a size is explicit
void f(vector<int>); // f's parameter is copy initialized
f(10); // error: can't use an explicit constructor to copy an argument
f(vector<int>(10));  // ok: directly construct a temporary vector from an int

If we want to use an explicit constructor, we must do so explicitly.

During copy initialization, the compiler is permitted (but not obligated) to skip the copy/move constructor and create the object directly. That is, the compiler is permitted to rewrite

1

string null_book = "9-999-99999-9"; // copy initialization

into

1

string null_book("9-999-99999-9"); // compiler omits the copy constructor

However, even if the compiler omits the call to the copy/move constructor, the copy/move constructor must exist and must be accessible at that point in the program.

The Copy-Assignment Operator

Overloaded operators are functions that have the name operator followed by the symbol for the operator being defined. Hence, the assignment operator is a function named operator=. The parameters in an overloaded operator represent the operands of the operator. When an operator is a member function, the left-hand operand is bound to implicit this parameter. The copy-assignment operator takes an argument of the same type as the class:

1
2
3
4

class Foo {
public:
    Foo& operator=(const Foo&); // assignment operator
};

To be consistent with assignment for built-in types, assignment operators usually return a reference to left-hand operand. As an example, the floowing is equivalent to the synthesized Sales_data copy-assignment operator:

1
2
3
4
5
6
7
8

// equivalent to the synthesized copy-assignment operator
Sales_data& Sales_data::operator=(const Sales_data &rhs)
{
    bookNo = rhs.bookNo;  // calls the string::operator=
    units_sold = rhs.units_sold;  // uses the built-in int assignment
    revenue = rhs.revenue;   // uses the built-in double
    return *this;  // return a reference to this object
}

The Destructor

Constructors initialize the nonstatic data members of an object and may do other work; destructors do whatever work is needed to free the resources used by an object and destroy the nonstatic data members of the object. The destructor is a member function with the name of the class prefixed by a tilde (~). It has no return value and takes no parameters:

1
2
3
4

class Foo {
public:
    ~Foo();  // destructor
};

In a constructor, members are initialized before the function body is executed, and members are initialized in the same order as they appear in the class. In a destructor, the function body is executed first and then the members are destroyed. Members are destroyed in reverse order from the order in which they were initialized.

The built-in types do not have destructors, so nothing is done to destroy members of built-in type.

Unlike ordinary pointers, the smart pointers are class types and have destructors. As a result, members that are smart pointers are automatically destroyed during the destruction phase.

The destructor is used automatically whenever an object of its type is destroyed:

• variables are destroyed when they go out of scope
• members of an object are destroyed when the object of which they are a part is destroyed
• elements in a container or an array are destroyed when the container is destroyed
• dynamically allocated objects are destroyed when the delete operator is applied to a pointer to the object
• temporary objects are destroyed at the end of the full expression in which the temporary was created

Note: the destructor is not run when a reference or a pointer to an object goes out of scope.

The members are automatically destroyed after the destructor body is run. It is important to realize that the destructor body does not directly destroy the members. Members are destroyed as part of the implicit destruction phase that follows the destructor body.

The Rule of Copy Control Operations

One rule of thumb to use when you decide whether a class needs to define its own versions of the copy-control members is to decide first whether the class needs a destructor. If the class needs a destructor, it almost surely needs a copy constructor and copy-assignment operator as well. The following example just explain this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

#include <iostream>
using namespace std;

class HasPtr {
public:
    HasPtr(const string &s = string()): ps(new string(s)) { }
    ~HasPtr() { delete ps; }
private:
    string *ps;
};

HasPtr f(HasPtr hp) {
	// copies the given HasPtr, multiple HasPtr objects may be pointing the same memory
    HasPtr ret = hp; 
    // ret and hp are destroyed, so HasPtr destructor will be called twice, this is an error
    return ret; 
}

int main() {
    HasPtr p("some values");
    f(p); // when f completes, the memory is freed
    HasPtr q(p); // now both p and q point to invalid memory
    return 0;
}

To avoid using the synthesized copy constructor and copy-assignment operator for this class, we should define our own version:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

class HasPtr {
public:
    HasPtr(const string &s = string()): ps(new string(s)) { }
    ~HasPtr() { delete ps; }
    HasPtr(const HasPtr &p): ps(new string(*p.ps)) { }
    HasPtr& operator =(const HasPtr &p) { ps = new string(*p.ps); }
    void print() { cout << *ps << endl; }
private:
    string *ps;
};

A second rule of thumb: If a class needs a copy constructor, it almost surely needs a copy-assignment operator. And vice versa, if the class needs an assignment operator, it almost surely needs a copy constructor as well. Nevertheless, needing either the copy constructor or the copy-assignment operator does not indicate the need for a destructor.

Using = default

Under the new standard, we can explicitly ask the compiler to generate the synthesized versions of the copy-control members by defining them as = default.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

class Sales_data {
public:
    // copy control, use default
    Sales_data() = default;
    Sales_data(const Sales_data&) = default;
    Sales_data& operator =(const Sales_data&);
    ~Sales_data() = default;
    // other members
};
Sales_data& Sales_data::operator=(const Sales_data &) = default;

When we specify = default on the declaration in the class body, the synthesized function is implicitly inline (just as any other member function defined in the body of the class). If we don’t want it inline, we can specify = default on the definition.

Preventing Copies

Under the new standard C++ 11, we can prevent copies by defining the copy constructor and copy-assignment operator as deleted functions. A deleted function is one that is declared but may not be used in any other way.

1
2
3
4
5
6

struct NoCopy {
    NoCopy() = default;
    ~NoCopy() = default;
    NoCopy(const NoCopy&) = delete; // no copy
    NoCopy& operator =(const NoCopy&) = delete; // no assignment
};

Unlike = default, = delete must appear on the first declaration of a deleted function. Also, we can specify = delete on any function. But the destructor should not be a deleted member, or that member cannot be destroyed.

For some classes, the compiler defines these synthesized members as deleted functions:

• synthesized destructor is defined as deleted if class has a member whose own destructor is deleted or is inaccessible (private).
• synthesized copy constructor is defined as deleted if the class has a member whose own copy constructor is deleted or inaccessible. It is also deleted if the class has a member with a deleted or inaccessible destructor.
• synthesized copy-assignment operator is defined as deleted if a member has a deleted or inaccessible copy-assignment operator, or if the class has a const or reference member.
• synthesized default constructor is defined as deleted if the class has a member with a deleted or inaccessible destructor; or has a reference member that does not have an in-class initializer; or has a const member whose type does not explicitly define a default constructor and that member does not have an in-class initializer.

In essence, these rules mean that if a class has a data member that cannot be default constructed, copied, assigned, or destroyed, then the corresponding member will be a deleted function.

It may be surprising that a member that has a deleted or inaccessible destructor causes the synthesized default and copy constructors to be defined as deleted. The reason is that without it, we could create objects that we could not destroy.

Prior to the new standard, classes prevented copies by declaring their copy constructor and copy-assignment operator as private. However, friends and members of the class can still make copies. To prevent these copies, we declare these members as private but do not define them. An attempt to use an undefined member results in a link-time failure. Classes that want to prevent copying should define their copy constructor and copy-assignment operator using = delete rather than making those members private.

Classes That Act Like Values

To decide what copying an object of type mean, we have two choices: We can define the copy operations to make the class behave like a value or like a pointer. Classes that behave like values have their own state. Classes that act like pointers share state. To illustrate these two approaches, we’ll make a class act like a value, then like a pointer.

To provide valuelike behavior, each object has to have its own copy of the resource that the class manages. There are two points to keep in mind when you write an assignment operator:

• assignment operator must work correctly if an object is assigned to itself
• most assignment operators share work with the destructor and copy constructor

A good pattern to use is to first copy the right-hand operand into a local temporary. After the copy is done, it is safe to destroy the existing members of the left-hand operand.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

class HasPtr {
public:
    HasPtr(const string &s = string()): ps(new string(s)), i(0) { }
    // To act like value, copy constructor should copy string, not just the pointer
    HasPtr(const HasPtr &p): ps(new string(*p.ps)), i(p.i) { }
    // To act like value, the copy assignment operator should free the object's
    // existing string and copy the string from its right-hand operand.
    HasPtr& operator =(const HasPtr &rhs);
    ~HasPtr() { delete ps; }
private:
    string *ps;
    int i;
};

HasPtr& HasPtr::operator=(const HasPtr &rhs) {
    auto newp = new string(*rhs.ps);
    delete ps;
    ps = newp;
    i = rhs.i;
    return *this;
}

Classes That Act Like Pointers

The easiest way to make a class act like a pointer is to use shared_ptr to manage the resource in the class. Copying (assigning) a shared_ptr copies (assigns) the pointer to which the shared_ptr points. Sometimes we want to manage a resource directly, so we will do our own reference counting. Reference counting works as follows:

• each constructor (other than copy constructor) creates a counter that keep track of how many objects share state
• copy constructor does not allocate a new counter, it just copies data members , including the counter. Then the copy constructor increments this shared counter, indicating that there is another user of that object’s state.
• the destructor decrements the counter. If the count goes to zero, the destructor deletes that state.
• copy assignment operator increments the right-hand operand’s counter and decrements the counter of the left-hand operand. If the counter for the left-hand operand goes to zero, we must destroy the state of the left-hand operand.

So where to put the reference count ? One way to solve this problem is to store the counter in dynamic memory.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

class HasPtr {
public:
    HasPtr(const string &s = string()): ps(new string(s)), i(0), use(new size_t(1)) { }
    HasPtr(const HasPtr &p): ps(p.ps), i(p.i), use(p.use) { ++*use; }
    HasPtr& operator =(const HasPtr &rhs);
    ~HasPtr();
private:
    string *ps;
    int i;
    size_t *use;
};

HasPtr::~HasPtr() {
    if (--*use == 0) {
        delete ps;
        delete use;
    }
}

HasPtr& HasPtr::operator=(const HasPtr &rhs) {
    ++*rhs.use;
    if (--*use == 0) {
        delete ps;
        delete use;
    }
    ps = rhs.ps;
    i = rhs.i;
    use = rhs.use;
    return *this;
}

Swap

In addition to defining the copy-control members, classes that manage resources often also define a function named swap. If a class defines its own swap, then the algorithm which need to exchange two elements uses that class-specific version. Otherwise, it uses the swap function defined by the library. The swap function involves a copy and two assignments:

1
2
3

HasPtr temp = v1; // make a temporary copy of the value of v1
v1 = v2; // assign the value of v2 to v1
v2 = temp; // assign the saved value of v1 to v2

In principle, none of the memory allocation is necessary. Rather than allocating new copies of the string, we’d like swap to swap the pointers. We can override the default behavior of swap by defining a version of swap that operate on our class.

1
2
3
4
5
6
7
8
9

class HasPtr {
    friend void swap(HasPtr&, HasPtr&);
    // other members
};

inline void swap(HasPtr &lhs, HasPtr &rhs){
    swap(lhs.ps, rhs.ps);
    swap(lhs.i, rhs.i);
}

Classes that define swap often use swap to define their assignment operator. These operators use a technique known as copy and swap. This technique swaps the left-hand operand with a copy of the right-hand operand:

1
2
3
4
5

HasPtr& HasPtr::operator=(HasPtr rhs) {
    // swap the content of the left-hand operand with local variable rhs
    swap(*this, rhs); // rhs now points to the memory this object had used
    return *this; // rhs is destroyed, which deletes the pointer in rhs
}

In this version of the assignment operator, the parameter is not a reference. Instead, we pass the right-hand operand by value. Copying a HasPtr allocates a new copy of that object’s string. When it finishes, rhs is destroyed and the destructor deletes the memory to which rhs now points. The interesting thing about this technique is that it automatically handles self assignment and is automatically exception safe.

Classes That Manage Dynamic Memory

Some classes need to allocate a varying amount of storage at run time. Such classes often can use a library container to hold their data. However, this strategy does not work for every class; some classes need to do their own allocation. Such classes generally must define their own copy-control members to manage the memory they allocate. As an example, we’ll implement a simplification of the library vector class.

In our StrVec class, We’ll use an allocator to obtain raw memory. Then we can use the allocator’s construct member to create objects in that space when we need to add an element, and use the destroy member to remove an element. Each StrVec will have three pointers into the space it uses for its elements:

• elements, which points to the first element in the allocated memory
• first_free, which points just after the last actual element
• cap, which points just past the end of the allocated memory

In addition to these pointers, StrVec will have a member named alloc that is an allocator. The alloc member will allocate the memory used by a StrVec. Our class will also have four utility functions:

• alloc_n_copy will allocate space and copy a given range of elements.
• free will destroy the constructed elements and deallocate the space.
• chk_n_alloc will ensure that there is room to add at least one more element to the StrVec. If there isn’t room for another element, chk_n_alloc will call reallocate to get more space.
• reallocate will reallocate the StrVec when it runs out of space

Copying a string copies the data because ordinarily after we copy a string, there are two users of that string. However, when reallocate copies the strings in a StrVec, there will be only one user of these strings after the copy. So copying the data in these strings is unnecessary.

Under the new standard, we can avoid copying the strings by using two facilities. First, the library classes define “move constructors”. The move constructors operate by “moving” resources from the given object to the object being constructed. For example, the string move constructor copies the pointer rather than allocating space for copying the characters themselves. Second, we’ll use a library function named move, defined in utility header. There are two points about move:

• When reallocate constructs strings in the new memory, it must call move to signal that it wants to use the string move constructor. If it omits this call, the copy constructor will be used.
• We usually do not provide a using declaration for move. When we use move, we call std::move, not move.

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130

#include <iostream>
#include <memory>
using namespace std;

class StrVec {
public:
    StrVec(): elements(nullptr), first_free(nullptr), cap(nullptr) { }
    StrVec(const StrVec& s);
    StrVec& operator =(const StrVec& rhs);
    ~StrVec() { free(); }

    void push_back(const string& s);
    size_t size() const { return first_free - elements; }
    size_t capacity() const { return cap - elements; }
    string* begin() const { return elements; }
    string* end() const { return first_free; }

    void reverse(size_t new_cap);
    void resize(size_t count);
    void resize(size_t count, const string& s);
private:
    allocator<string> alloc;
    void chk_n_alloc() { if (size() == capacity()) reallocate(); }
    pair<string*, string*> alloc_n_copy(const string* b, const string* e);
    void alloc_n_move(size_t new_cap);
    void free();
    void reallocate();
    string *elements;
    string *first_free;
    string *cap;
};

void StrVec::push_back(const string& s) {
    // ensure there is room for another element
    chk_n_alloc();
    // construct a copy of s in the element to which first_free points
    // the string copy constructor will be called
    alloc.construct(first_free++, s);
}

// allocate storage and copy elements into the newly allocated space
pair<string*, string*> StrVec::alloc_n_copy(const string* b, const string* e) {
    auto data = alloc.allocate(e - b);
    // the first data points to the start of the allocated memory
    // the second points to one element past the last constructed element
    return {data, uninitialized_copy(b, e, data)};
}

void StrVec::free() {
    if (elements) {
        // destroy old elements in reverse order
        // destroy function runs the string destructor
        for (auto p = first_free; p != elements; )
            alloc.destroy(--p);
        alloc.deallocate(elements, cap - elements);
    }
}

StrVec::StrVec(const StrVec &s) {
    auto newdata = alloc_n_copy(s.begin(), s.end());
    elements = newdata.first;
    first_free = cap = newdata.second;
}

StrVec& StrVec::operator=(const StrVec &rhs) {
    auto data = alloc_n_copy(rhs.begin(), rhs.end());
    free();
    elements = data.first;
    first_free = cap = data.second;
    return *this;
}

void StrVec::reallocate() {
    auto newcapacity = size() ? 2 * size() : 1;
    alloc_n_move(newcapacity);
}

void StrVec::alloc_n_move(size_t new_cap) {
    // allocate new memory
    auto newdata = alloc.allocate(new_cap);
    // move data from old memory to the new
    auto dest = newdata; // points the next free position in the new array
    auto elem = elements; // points to the next element in the old array
    for (size_t i = 0; i != size(); ++i) {
        // move returns a result that causes construct to use the string move constructor
        // the memory managed by those strings will not be copied, and each string we construct
        // will take over ownership of the memory from the string to which elem points
        alloc.construct(dest++, std::move(*elem++));
    }
    free();
    elements = newdata;
    first_free = dest;
    cap = elements + new_cap;
}

void StrVec::reverse(size_t new_cap) {
    if (new_cap > capacity()) {
        alloc_n_move(new_cap);
    }
}

void StrVec::resize(size_t count) {
    resize(count, string());
}

void StrVec::resize(size_t count, const string &s) {
    if (count < size()) {
        while (first_free != elements + count)
            alloc.destroy(--first_free);
    }
    else if (count > size()) {
        if (count > capacity())
            reverse(count * 2);
        for (size_t i = size(); i != count; ++i)
            alloc.construct(first_free++, s);
    }
}

int main() {
    StrVec words;
    words.reverse(10);
    cout << words.size() << " " << words.capacity() << endl;
    words.push_back("how");
    words.push_back("are");
    words.push_back("you");
    words.resize(2);
    cout << words.size() << " " << words.capacity() << endl;
    for (auto it = words.begin(); it != words.end(); ++it) cout << *it << " ";
    return 0;
}

Note: One of the major features in the new standard is the ability to move rather than copy an object. The library containers, string, and shared_ptr clases support move as well as copy. The IO and unique_ptr classes can be moved but not copied.

Rvalue References

To support move operations, the new standard introduced a new kind of reference, an rvalue reference. An rvalue reference is a reference that must be bound to an rvalue. An rvalue reference is obtained by using && rather than &. As we’ll see, rvalue references have the important property that they may be bound only to an object that is about to be destroyed. Generally speaking, an lvalue expression refers to an object’s identity whereas an rvalue expression refers to an object’s value.

1
2
3
4
5
6
7
8

int i = 42;
int &r = i; // ok: r refers to i
int &&rr = i; // error: cannot bind an rvalue reference to an lvalue

int &r2 = i * 42; // error: i * 42 is an rvalue
const int &r3 = i * 42; // ok: we can bind a reference to const to an
rvalue
int &&rr2 = i * 42; // ok: bind rr2 to the result of the multiplication

Variables are lvalues. As a result, we cannot bind an rvalue reference to a variable defined as an rvalue reference type:

1
2

int &&rr1 = 42; // ok: literals are rvalues
int &&rr2 = rr1; // error: the expression rr1 is an lvalue!

Alghough we cannot directly bind an rvalue reference to an lvalue, we can explicitly cast an lvalue to its corresponding rvalue reference type. We can also obtain an rvalue reference bound to an lvaue by calling a new library function named move, which is defined in the utility header. The move function uses facilities to return an rvalue reference to its given object.

1

int &&rr3 = std::move(rr1); // ok

Calling move tells the compiler that we have an lvalue that we want to treat as if it were an rvalue. It is essential to realize that the call to move promises that we do not intend to use rr1 again except to assign to it or to destroy it. After a call to move, we cannot make any assumptions about the value of the moved-from object. We can destroy a moved-from object and can assign a new value to it, but we cannot use the value of a moved-from object.

Code that uses move should use std::move, not move. Doing so avoids potential name collisions.

Move Constructor

To enable move operations for our own types, we define a move constructor and a move-assignment operator. These members are similar to the corresponding copy operations, but they “steal” resources from their given object rather than copy them.

Like the copy constructor, the move constructor has an initial parameter that is a reference to the class type. Differently from the copy constructor, the reference parameter in the move constructor is an rvalue reference. As in the copy constructor, any additional parameters must all have default arguments. In addition to moving resources, the move constructor must ensure that the moved-from object is left in a state such that destroying that object will be harmless. In particular, once its resources are moved, the original object must no longer point to those moved resources. Responsibility for those resources has been assumed by the newly created object.

1
2
3
4

StrVec::StrVec(StrVec &&s) noexcept : elements(s.elements), first_free(s.first_free), cap(s.cap) {
    // leave s in a state in which it is safe to run the destructor
    s.elements = s.first_free = s.cap = nullptr;
}

Unlike the copy constructor, the move constructor does not allocate any new memory; it takes over the memory in the given object. As a result, move operations ordinarily will not throw any exceptions. As we’ll see, unless the library knows that our move constructor won’t throw, it will do extra work to cater to the possibliity that moving an object of our class type might throw. One way inform the library is to specify noexcept on our constructor. We specify noexcept on a function after its parameter list. Move constructors and move assignment operators that cannot throw exceptions should be marked as noexcept.

So why noexcept is needed ? The push_back operation in the class StrVec might require that the vector be reallocated. As we’ve just seen, moving an object generally changes the value of the moved-from object. If reallocation uses a move constructor which throw an exception after moving some but not all of elements, the moved-from elements in the old space would have been changed, and the unconstructed elements in the new space would not yet exist. In this case, vector would be unable to meet its requirement that the vector is left unchanged. On the other hand, if vector uses the copy constructor and an exception happens, it can easily meet this requirement. In this case, while the elements are being constructed in the new memory, the old elements remain unchanged. If we want objects of our type to be moved rather than copied in circumstances such as vector reallocation, we must explicity tell the library that our move constructor is safe to use by using noexcept.

Move-Assignment Operator

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

StrVec& StrVec::operator=(StrVec &&rhs) noexcept {
    // direct test for self-assignment
    if (this != &rhs) {
        free();
        elements = rhs.elements;
        first_free = rhs.first_free;
        cap = rhs.cap;
        // leave rhs in a destructible state
        rhs.elements = rhs.first_free = rhs.cap = nullptr;
    }
    return *this;
}

Moving from an object does not destroy that object: Sometime after the move operation completes, the moved-from object will be destroyed. Therefore, when we write a move operation, we must ensure that the moved-from object is in a state in which the destructor can be run. After a move operation, the moved-from object must remain a valid, destructible object but users may make no assumptions about its value.

The Synthesized Move Operations

Recall that if we do not declare our own copy constructor or copy-assignment operator the compiler always synthesizes these operations. The compiler will synthesize a move constructor or a move-assignment operator only if the class doesn’t define any of its own copy-control members and if every nonstatic data member of the class can be moved.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// the compiler will synthesize the move operations for X and hasX
struct X {
	int i; // built-in types can be moved
	std::string s; // string defines its own move operations
};

struct hasX {
	X mem; // X has synthesized move operations
};
X x, x2 = std::move(x); // uses the synthesized move constructor
hasX hx, hx2 = std::move(hx); // uses the synthesized move constructor

Move Operation Defined as Deleted

Unlike the copy operations, a move operation is never implicitly defined as a deleted function. However, if we explicitly ask the compiler to generate a move operation by using = default, and the compiler is unable to move all the members, then the move operation will be defined as deleted. The rules for when a synthesized move operation is defined as deleted:

• Unlike the copy constructor, the move constructor is defined as deleted if the class has a member that defines its own copy constructor but does not also define a move constructor, or if the class has a member that doesn’t define its own copy operations and for which the compiler is unable to synthesize a move constructor. Similarly for move-assignment.
• The move constructor or move-assignment operator is defined as deleted if the class has a member whose own move constructor or move-assignment operator is deleted or inaccessible.
• Like the copy constructor, the move constructor is defined as deleted if the destructor is deleted or inaccessible.
• Like the copy-assignment operator, the move-assignment operator is defined as deleted if the class has a const or reference member.

Note: Classes that define a move constructor or move-assignment operator must also define their own copy operations. Otherwise, those members are deleted by default.

Which Constructor to Use

When a class has both a move constructor and a copy constructor, the compiler uses ordinary function matching to determine which constructor to use. Similarly for assignment. If a class has no move constructor, function matching ensures that objects of that type are copied, even if we attempt to move them by calling move.

Copy-and-Swap Assignment Operators and Move

1
2
3
4
5
6
7
8

class HasPtr {
public:
	// added move constructor
	HasPtr(HasPtr &&p) noexcept : ps(p.ps), i(p.i) {p.ps = 0;}
	// assignment operator is both the move-assignment and copy-assignment operator
	HasPtr& operator=(HasPtr rhs) { swap(*this, rhs); return *this; }
	// other members
};

If we add a move constructor to this class, it will effectively get a move assignment operator as well. Now let’s look at the assignment operator. That operator has a nonreference parameter, which means the parameter is copy initialized. Copy initialization uses either the copy constructor or the move constructor; lvalues are copied and rvalues are moved. As a result, this single assignment operator acts as both the copy-assignment and move-assignment operator.

The third rule of thumb: All five copy-control members should be thought of as a unit. Ordinarily, if a class defines any of these operations, it usually should define them all.

Move Iterators

The reallocate member of StrVec used a for loop to call construct to copy the elements from the old memory to the new. As an alternative to writing that loop, it would be easier if we could call uninitialized_copy to construct the newly allocated space. However, uninitialized_copy does what it says: It copies the elements. There is no analogous library function to “move” objects into unconstructed memory.

Instead, the new library defines a move iterator adaptor. A move iterator adapts its given iterator by changing the behavior of the iterator’s dereference operator. Ordinarily, an iterator dereference operator returns an lvalue reference to the element. Unlike other iterators, the dereference operator of a move iterator yields an rvalue reference.

We transform an ordinary iterator to a move iterator by calling the library make_move_iterator function. This function takes an iterator and returns a move iterator. All of the original iterator’s other operations work as usual.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

void StrVec::reallocate()
{
    // allocate space for twice as many elements as the current size
    auto newcapacity = size() ? 2 * size() : 1;
    auto first = alloc.allocate(newcapacity);
    // move the elements
    auto last = uninitialized_copy(make_move_iterator(begin()), make_move_iterator(end()), first);
    free(); // free the old space
    elements = first; // update the pointers
    first_free = last;
    cap = elements + newcapacity;
}

uninitialized_copy calls construct on each element in the input sequence to “copy” that element into the destination. That algorithm uses the iterator dereference operator to fetch elements from the input sequence. Because we passed move iterators, the dereference operator yields an rvalue reference, which means construct will use the move constructor to construct the elements. You should pass move iterators to algorithms only when you are confident that the algorithm does not access an element after it has assigned to that element or passed that element to a user-defined function.

Because a moved-from object has indeterminate state, calling std::move on an object is a dangerous operation. When we call move, we must be absolutely certain that there can be no other users of the moved-from object.

Rvalue References and Member Functions

Member functions other than constructors and assignment can benefit from providing both copy and move versions. For example, the library containers that define push_back provide two versions:

1
2

void push_back(const X&); // copy: binds to any kind of X
void push_back(X&&); // move: binds only to modifiable rvalues of type X

Overloaded functions that distinguish between moving and copying a parameter typically have one version that takes a const T& and one that takes a T&&. Ordinarily, there is no need to define versions of the operation that take a const X&& or a (plain) X&. Usually, we pass an rvalue reference when we want to “steal” from the argument. In order to do so, the argument must not be const. Similarly, copying from an object should not change the object being copied.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

void StrVec::push_back(const string& s)
{
	chk_n_alloc(); // ensure that there is room for another element
	// construct a copy of s in the element to which first_free points
	alloc.construct(first_free++, s);
}

void StrVec::push_back(string &&s)
{
	chk_n_alloc(); // reallocates the StrVec if necessary
	alloc.construct(first_free++, std::move(s));
}

The difference is that the rvalue reference version of push_back calls move to pass its parameter to construct. As we’ve seen, the construct function uses the type of its second and subsequent arguments to determine which constructor to use.

1
2
3
4

StrVec vec; // empty StrVec
string s = "some string or another";
vec.push_back(s); // calls push_back(const string&)
vec.push_back("done"); // calls push_back(string&&)

When we call push_back the type of the argument determines whether the new element is copied or moved into the container. These calls differ as to whether the argument is an lvalue (s) or an rvalue (the temporary string created from “done”).

The reference qualifier

The following usage can be surprising when we assign to the rvalue. Prior to the new standard, there was no way to prevent such usage. In order to maintain backward compatability, the library classes continue to allow assignment to rvalues, However, we might want to prevent such usage in our own classes. In this case, we’d like to force the left-hand operand to be an lvalue.

1
2

string s1 = "a value", s2 = "another";
s1 + s2 = "wow!";

C++ 11, We indicate the lvalue/rvalue property of “this” in the same way that we define const member functions; we place a reference qualifier after the parameter list.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

class Foo {
public:
	Foo &operator=(const Foo&) &; // may assign only to modifiable lvalues
};

Foo &Foo::operator=(const Foo &rhs) &
{
	// do whatever is needed to assign rhs to this object
	return *this;
}

The reference qualifier can be either & or &&, indicating that “this” may point to an lvalue or rvalue, respectively. Like the const qualifier, a reference qualifier may appear only on a (nonstatic) member function and must appear in both the declaration and definition of the function.

A function can be both const and reference qualified. In such cases, the reference qualifier must follow the const qualifier:

1
2
3
4
5

class Foo {
public:
	Foo someMem() & const; // error: const qualifier must come first
	Foo anotherMem() const &; // ok: const qualifier comes first
};

Overloading and Reference Functions

Just as we can overload a member function based on whether it is const, we can also overload a function based on its reference qualifier.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

class Foo {
public:
    Foo sorted() &&; // may run on modifiable rvalues
    Foo sorted() const &; // may run on any kind of Foo
    // other members of Foo
private:
    vector<int> data;
};

// this object is an rvalue, so we can sort in place
Foo Foo::sorted() && {
    sort(data.begin(), data.end());
    return *this;
}

// this object is either const or it is an lvalue; either way we can't sort in place
Foo Foo::sorted() const & {
    Foo ret(*this); // make a copy
    sort(ret.data.begin(), ret.data.end()); // sort the copy
    return ret; // return the copy
}

The object is an rvalue, which means it has no other users, so we can change the object itself. When we run sorted on a const rvalue or on an lvalue, we can’t change this object, so we copy data before sorting it. Overload resolution uses the lvalue/rvalue property of the object that calls sorted to determine which version is used:

1
2

retVal().sorted(); // retVal() is an rvalue, calls Foo::sorted() &&
retFoo().sorted(); // retFoo() is an lvalue, calls Foo::sorted() const &

When we define two or more members that have the same name and the same parameter list, we must provide a reference qualifier on all or none of those functions:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

class Foo {
public:
    Foo sorted() &&;
    Foo sorted() const; // error: must have reference qualifier
    // Comp is type alias for the function type (see § 6.7 (p. 249))
    // that can be used to compare int values
    using Comp = bool(const int&, const int&);
    Foo sorted(Comp*); // ok: different parameter list
    Foo sorted(Comp*) const; // ok: neither version is reference qualified
};

Overloaded Operations and Conversions

C++ lets us define what the operators mean when applied to objects of class type. It also lets us define conversions for class types. Class-type conversions are used like the built-in conversions to implicitly convert an object of one type to another type when needed. Operator overloading lets us define the meaning of an operator when applied to operand(s) of a class type. Judicious use of operator overloading can make our programs easier to write and easier to read.

Basic Concepts

Overloaded operators are functions with special names: the keyword operator followed by the symbol for the operator being defined. An overloaded operator function has the same number of parameters as the operator has operands. When an overloaded operator is a member function, this is bound to the left-hand operand. Member operator functions have one less (explicit) parameter than the number of operands.

We cannot change the meaning of an operator when applied to operands of built-in type. We can overload only existing operators and cannot invent new operator symbols. For example, we cannot define operator** to provide exponentiation. Four symbols (+, -, *, and &) serve as both unary and binary operators. Either or both of these operators can be overloaded. An overloaded operator has the same precedence and associativity as the corresponding built-in operator.

Calling Overloaded Operator Directly

1
2
3

// equivalent calls to a nonmember operator function
data1 + data2;            // normal expression
operator+(data1, data2);  // equivalent function call

These calls are equivalent: Both call the nonmember function operator+, passing data1 as the first argument and data2 as the second. And we call a member operator function explicitly in the same way that we call any other member function.

1
2

data1 += data2;          // expression-based ''call''
data1.operator+=(data2); // equivalent call to a member operator function

Some Operators Shouldn’t Be Overloaded

Because the overloaded versions of these operators do not preserve order of evaluation and/or short-circuit evaluation, it is usually a bad idea to overload them. Ordinarily, the comma, address-of, logical AND , and logical OR operators should not be overloaded.

Use Definitions That Are Consistent with the Built-in Meaning

• If the class does IO, define the shift operators to be consistent with how IO is done for the built-in types.
• If the class has an operation to test for equality, define operator==. If the class has operator==, it should usually have operator!= as well.
• If the class has a single, natural ordering operation, define operator<. If the class has operator<, it should probably have all of the relational operators.
• The return type of an overloaded operator usually should be compatible with the return from the built-in version of the operator.

Operator overloading is most useful when there is a logical mapping of a built-in operator to an operation on our type.

Choosing Member or Nonmember

When we define an overloaded operator, we must decide whether to make the operator a class member or an ordinary nonmember function.

• The assignment (=), subscript ([]), call (()), and member access arrow (->) operators must be defined as members.
• The compound-assignment operators ordinarily ought to be members. However, unlike assignment, they are not required to be members.
• Operators that change the state of their object or that are closely tied to their given type—such as increment, decrement, and dereference—usually should be members.
• Symmetric operators—those that might convert either operand, such as the arithmetic, equality, relational, and bitwise operators—usually should be defined as ordinary nonmember functions.

Programmers expect to be able to use symmetric operators in expressions with mixed types. For example, we can add an int and a double. The addition is symmetric because we can use either type as the left-hand or the right-hand operand. If we want to provide similar mixed-type expressions involving class objects, then the operator must be defined as a nonmember function. When we define an operator as a member function, then the left-hand operand must be an object of the class of which that operator is a member. For example:

1
2
3

string s = "world";
string t = s + "!";  // ok: we can add a const char* to a string
string u = "hi" + s; // would be an error if + were a member of string

If operator+ were a member of the string class, the first addition would be equivalent to s.operator+("!"). Likewise, “hi” + s would be equivalent to “hi”.operator+(s). However, the type of “hi” is const char*, and that is a built-in type; it does not even have member functions.

Overloading the Output Operator

Ordinarily, the first parameter of an output operator is a reference to a nonconst ostream object. The ostream is nonconst because writing to the stream changes its state. The parameter is a reference because we cannot copy an ostream object. The second parameter ordinarily should be a reference to const of the class type we want to print. The parameter is a reference to avoid copying the argument. It can be const because (ordinarily) printing an object does not change that object. To be consistent with other output operators, operator« normally returns its ostream parameter.

1
2
3
4
5
6

ostream &operator<<(ostream &os, const Sales_data &item)
{
    os << item.isbn() << " " << item.units_sold << " "
    << item.revenue << " " << item.avg_price();
    return os;
}

Generally, output operators should print the contents of the object, with minimal formatting. They should not print a newline.

Input and output operators that conform to the conventions of the iostream library must be ordinary nonmember functions.

Overloading the Input Operator

Ordinarily the first parameter of an input operator is a reference to the stream from which it is to read, and the second parameter is a reference to the (nonconst) object into which to read. The operator usually returns a reference to its given stream.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

istream &operator>>(istream &is, Sales_data &item)
{
    double price; // no need to initialize; we'll read into price before we use it
    is >> item.bookNo >> item.units_sold >> price;
    if (is) // check that the inputs succeeded
        item.revenue = item.units_sold * price;
    else
        item = Sales_data(); // input failed: give the object the default state
    return is;
}

Input operators must deal with the possibility that the input might fail; output operators generally don’t bother. Some input operators need to do additional data verification. In such cases, the input operator might need to set the stream’s condition state to indicate failure, even though technically speaking the actual IO was successful. Usually an input operator should set only the failbit. Setting eofbit would imply that the file was exhausted, and setting badbit would indicate that the stream was corrupted. These errors are best left to the IO library itself to indicate.

Arithmetic and Relational Operators

Ordinarily, we define the arithmetic and relational operators as nonmember functions in order to allow conversions for either the left- or right-hand operand.

1
2
3
4
5
6
7
8

// assumes that both objects refer to the same book
Sales_data
operator+(const Sales_data &lhs, const Sales_data &rhs)
{
    Sales_data sum = lhs; // copy data members from lhs into sum
    sum += rhs; // add rhs into sum
    return sum;
}

Classes that define both an arithmetic operator and the related compound assignment ordinarily ought to implement the arithmetic operator by using the compound assignment.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

bool operator==(const Sales_data &lhs, const Sales_data &rhs)
{
    return lhs.isbn() == rhs.isbn() &&
        lhs.units_sold == rhs.units_sold &&
        lhs.revenue == rhs.revenue;
}
bool operator!=(const Sales_data &lhs, const Sales_data &rhs)
{
    return !(lhs == rhs);
}

Classes for which there is a logical meaning for equality normally should define operator==. Classes that define == make it easier for users to use the class with the library algorithms.

For Sales_data, there is no single logical definition of <. Thus, it is better for this class not to define < at all. If a single logical definition for < exists, classes usually should define the < operator. However, if the class also has ==, define < only if the definitions of < and == yield consistent results.

Assignment Operators

In addition to the copy- and move-assignment operators that assign one object of the class type to another object of the same type, a class can define additional assignment operators that allow other types as the right-hand operand. As one example, the library vector class defines a third assignment operator that takes a braced list of elements. We can add this operator to our StrVec class:

1
2
3
4
5

class StrVec {
public:
    StrVec &operator=(std::initializer_list<std::string>);
    // other members as in § 13.5 (p. 526)
};

Assignment operators can be overloaded. Assignment operators, regardless of parameter type, must be defined as member functions.

Compound-Assignment Operators

Compound assignment operators are not required to be members. However, we prefer to define all assignments, including compound assignments, in the class. For example:

1
2
3
4
5
6
7
8

// member binary operator: left-hand operand is bound to the implicit this pointer
// assumes that both objects refer to the same book
Sales_data& Sales_data::operator+=(const Sales_data &rhs)
{
    units_sold += rhs.units_sold;
    revenue += rhs.revenue;
    return *this;
}

Assignment operators must, and ordinarily compound-assignment operators should, be defined as members. These operators should return a reference to the left-hand operand.

Subscript Operator

Classes that represent containers from which elements can be retrieved by position often define the subscript operator, operator[]. The subscript operator must be a member function. If a class has a subscript operator, it usually should define two versions: one that returns a plain reference and the other that is a const member and returns a reference to const.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

class StrVec {
public:
    std::string& operator[](std::size_t n)
        { return elements[n]; }
    const std::string& operator[](std::size_t n) const
        { return elements[n]; }
    // other members as in § 13.5 (p. 526)
private:
    std::string *elements; // pointer to the first element in the array
};

Increment and Decrement Operators

The increment (++) and decrement (–) operators are most often implemented for iterator classes. These operators let the class move between the elements of a sequence. Classes that define increment or decrement operators should define both the prefix and postfix versions. These operators usually should be defined as members.

1
2
3
4
5
6
7

class StrBlobPtr {
public:
    // increment and decrement
    StrBlobPtr& operator++(); // prefix operators
    StrBlobPtr& operator--();
    // other members as before
};

To be consistent with the built-in operators, the prefix operators should return a reference to the incremented or decremented object.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

// prefix: return a reference to the incremented/decremented object
StrBlobPtr& StrBlobPtr::operator++()
{
    // if curr already points past the end of the container, can't increment it
    check(curr, "increment past end of StrBlobPtr");
    ++curr; // advance the current state
    return *this;
}
StrBlobPtr& StrBlobPtr::operator--()
{
    // if curr is zero, decrementing it will yield an invalid subscript
    --curr; // move the current state back one element
    check(-1, "decrement past begin of StrBlobPtr");
    return *this;
}

There is one problem with defining both the prefix and postfix operators: Normal overloading cannot distinguish between these operators. To solve this problem, the postfix versions take an extra (unused) parameter of type int.

1
2
3
4
5
6
7

class StrBlobPtr {
public:
    // increment and decrement
    StrBlobPtr operator++(int); // postfix operators
    StrBlobPtr operator--(int);
    // other members as before
};

To be consistent with the built-in operators, the postfix operators should return the old (unincremented or undecremented) value. That value is returned as a value, not a reference. The postfix versions have to remember the current state of the object before incrementing the object:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

// postfix: increment/decrement the object but return the unchanged value
StrBlobPtr StrBlobPtr::operator++(int)
{
    // no check needed here; the call to prefix increment will do the check
    StrBlobPtr ret = *this; // save the current value
    ++*this; // advance one element; prefix ++ checks the increment
    return ret; // return the saved state
}
StrBlobPtr StrBlobPtr::operator--(int)
{
    // no check needed here; the call to prefix decrement will do the check
    StrBlobPtr ret = *this; // save the current value
    --*this; // move backward one element; prefix -- checks the decrement
    return ret; // return the saved state
}

The int parameter is not used, so we do not give it a name. If we want to call the postfix version using a function call, then we must pass a value for the integer argument:

1
2
3

StrBlobPtr p(a1); // p points to the vector inside a1
p.operator++(0); // call postfix operator++
p.operator++(); // call prefix operator++

Member Access Operators

The dereference (*) and arrow (->) operators are often used in classes that represent iterators and in smart pointer classes.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

class StrBlobPtr {
public:
    std::string& operator*() const
    { 
        auto p = check(curr, "dereference past end");
        return (*p)[curr]; // (*p) is the vector to which this object points
    }
    std::string* operator->() const
    {
        // delegate the real work to the dereference operator
        return & this->operator*();
    }
    // other members as before
};

Operator arrow must be a member. The dereference operator is not required to be a member but usually should be a member as well. The overloaded arrow operator must return either a pointer to a class type or an object of a class type that defines its own operator arrow.

Function-Call Operator

Classes that overload the call operator allow objects of its type to be used as if they were a function. Because such classes can also store state, they can be more flexible than ordinary functions.

1
2
3
4
5
6

struct absInt {
    int operator()(int val) const 
    {
        return val < 0 ? -val : val;
    }
};

We use the call operator by applying an argument list to an absInt object in a way that looks like a function call. Even though absObj is an object, not a function, we can “call” this object. Calling an object runs its overloaded call operator.

1
2
3

int i = -42;
absInt absObj; // object that has a function-call operator
int ui = absObj(i); // passes i to absObj.operator()

The function-call operator must be a member function. A class may define multiple versions of the call operator, each of which must differ as to the number or types of their parameters. Objects of classes that define the call operator are referred to as function objects. Such objects “act like functions” because we can call them.

As an example, we’ll define a class that prints a string argument.

1
2
3
4
5
6
7
8

class PrintString {
public:
    PrintString(ostream &o = cout, char c = ' '): os(o), sep(c) { }
    void operator()(const string &s) const { os << s << sep; }
private:
    ostream &os; // stream on which to write
    char sep; // character to print after each output
};

When we define PrintString objects, we can use the defaults or supply our own values for the separator or output stream:

1
2
3
4

PrintString printer; // uses the defaults; prints to cout
printer(s); // prints s followed by a space on cout
PrintString errors(cerr, '\n');
errors(s); // prints s followed by a newline on cerr

Function objects are most often used as arguments to the generic algorithms. For example, we can use the library for_each algorithm and our PrintString class to print the contents of a container:

1

for_each(vs.begin(), vs.end(), PrintString(cerr, '\n'));

Lambdas Are Function Objects

In the previous section, we used a PrintString object as an argument in a call to for_each. This usage is similar to the programs that used lambda expressions. When we write a lambda, the compiler translates that expression into an unnamed object of an unnamed class. The classes generated from a lambda contain an overloaded function-call operator. For example, the lambda that we passed as the last argument to stable_sort:

1
2
3
4

// sort words by size, but maintain alphabetical order for words of the same size
stable_sort(words.begin(), words.end(),
            [](const string &a, const string &b)
            { return a.size() < b.size();});

acts like an unnamed object of a class that would look something like

1
2
3
4
5

class ShorterString {
public:
    bool operator()(const string &s1, const string &s2) const
    { return s1.size() < s2.size(); }
};

By default, lambdas may not change their captured variables. As a result, by default, the function-call operator in a class generated from a lambda is a const member function. If the lambda is declared as mutable, then the call operator is not const. We can rewrite the call to stable_sort to use this class instead of the lambda expression:

1

stable_sort(words.begin(), words.end(), ShorterString());

As we’ve seen, when a lambda captures a variable by reference, the compiler is permitted to use the reference directly without storing that reference as a data member in the generated class. In contrast, variables that are captured by value are copied into the lambda. As a result, classes generated from lambdas that capture variables by value have data members corresponding to each such variable. As an example, the lambda that we used to find the first string whose length was greater than or equal to a given bound:

1
2
3

// get an iterator to the first element whose size() is >= sz
auto wc = find_if(words.begin(), words.end(),
                [sz](const string &a)

would generate a class that looks something like

1
2
3
4
5
6
7

class SizeComp {
    SizeComp(size_t n): sz(n) { } // parameter for each captured variable
    // call operator with the same return type, parameters, and body as the lambda
    bool operator()(const string &s) const { return s.size() >= sz; }
private:
    size_t sz; // a data member for each variable captured by value
};

Unlike our ShorterString class, this class has a data member and a constructor to initialize that member. This synthesized class does not have a default constructor; to use this class, we must pass an argument:

1
2

// get an iterator to the first element whose size() is >= sz
auto wc = find_if(words.begin(), words.end(), SizeComp(sz));

Classes generated from a lambda expression have a deleted default constructor, deleted assignment operators, and a default destructor. Whether the class has a defaulted or deleted copy/move constructor depends in the usual ways on the types of the captured data members.

Library-Defined Function Objects

The standard library defines a set of classes that represent the arithmetic, relational, and logical operators. Each class defines a call operator that applies the named operation. These classes are templates to which we supply a single type. That type specifies the parameter type for the call operator. For example, plus applies the string addition operator to string objects; for plus the operands are ints; and so on.

1
2
3
4
5
6
7
8

plus<int> intAdd; // function object that can add two int values
negate<int> intNegate; // function object that can negate an int value
// uses intAdd::operator(int, int) to add 10 and 20
int sum = intAdd(10, 20); // equivalent to sum = 30
sum = intNegate(intAdd(10, 20)); // equivalent to sum = 30
// uses intNegate::operator(int) to generate -10 as the second parameter
// to intAdd::operator(int, int)
sum = intAdd(10, intNegate(10)); // sum = 0

These types are defined in the functional header.

1
2
3
4
5
6
7
8

Arithmetic      Relational          Logical

plus<T>         equal_to<T>         logical_and<T>
minus<T>        not_equal_to<T>     logical_or<T>
multiplies<T>   greater<T>          logical_not<T>
divides<T>      greater_equal<T>
modulus<T>      less<T>
negate<T>       less_equal<T>

The function-object classes that represent operators are often used to override the default operator used by an algorithm. As we’ve seen, by default, the sorting algorithms use operator<, which ordinarily sorts the sequence into ascending order. To sort into descending order, we can pass an object of type greater.

1
2

// passes a temporary function object that applies the < operator to two strings
sort(svec.begin(), svec.end(), greater<string>());

One important aspect of these library function objects is that the library guarantees that they will work for pointers. Recall that comparing two unrelated pointers is undefined. However, we might want to sort a vector of pointers based on their addresses in memory.

1
2
3
4
5
6

vector<string *> nameTable; // vector of pointers
// error: the pointers in nameTable are unrelated, so < is undefined
sort(nameTable.begin(), nameTable.end(),
    [](string *a, string *b) { return a < b; });
// ok: library guarantees that less on pointer types is well defined
sort(nameTable.begin(), nameTable.end(), less<string*>());

Callable Objects and function

C++ has several kinds of callable objects: functions and pointers to functions, lambdas, objects created by bind, and classes that overload the function-call operator. Sometimes we want to treat several callable objects that share a call signature as if they had the same type. For example, consider the following different types of callable objects:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

// ordinary function
int add(int i, int j) { return i + j; }
// lambda, which generates an unnamed function-object class
auto mod = [](int i, int j) { return i % j; };
// function-object class
struct div 
{
    int operator()(int denominator, int divisor) 
    {
        return denominator / divisor;
    }
};

Even though each has a distinct type, they all share the same call signature:

1

int(int, int)

We might want to use these callables to build a simple desk calculator. To do so, we’d want to define a function table to store “pointers” to these callables. In C++, function tables are easy to implement using a map.

1
2

// maps an operator to a pointer to a function taking two ints and returning an int
map<string, int(*)(int,int)> binops;

We could put a pointer to add into binops as follows:

1
2

// ok: add is a pointer to function of the appropriate type
binops.insert({"+", add});

However, we can’t store mod or div in binops:

1

binops.insert({"%", mod}); // error: mod is not a pointer to function

The problem is that mod is a lambda, and each lambda has its own class type. That type does not match the type of the values stored in binops. We can solve this problem using a new library type named function that is defined in the functional header. function is a template. We can declare a function type that can represent callable objects that return an int result and have two int parameters.

1
2
3
4
5
6
7

function<int(int, int)> f1 = add; // function pointer
function<int(int, int)> f2 = div(); // object of a function-object class
function<int(int, int)> f3 = [](int i, int j) // lambda
{ return i * j; };
cout << f1(4,2) << endl; // prints 6
cout << f2(4,2) << endl; // prints 2
cout << f3(4,2) << endl; // prints 8

We can now redefine our map using this function type:

1

map<string, function<int(int, int)>> binops;

We can add each of our callable objects, be they function pointers, lambdas, or function objects, to this map:

1
2
3
4
5
6

map<string, function<int(int, int)>> binops = {
{"+", add}, // function pointer
{"-", std::minus<int>()}, // library function object
{"/", div()}, // user-defined function object
{"*", [](int i, int j) { return i * j; }}, // unnamed lambda
{"%", mod} }; // named lambda object

When we index binops, we get a reference to an object of type function. The function type overloads the call operator. That call operator takes its own arguments and passes them along to its stored callable object:

1
2
3
4
5

binops["+"](10, 5); // calls add(10, 5)
binops["-"](10, 5); // uses the call operator of the minus<int> object
binops["/"](10, 5); // uses the call operator of the div object
binops["*"](10, 5); // calls the lambda function object
binops["%"](10, 5); // calls the lambda function object

The function class in the new library is not related to classes named unary_function and binary_function that were part of earlier versions of the library. These classes have been deprecated by the more general bind function.

Conversion Operators

Converting constructors and conversion operators define class-type conversions. Such conversions are also referred to as user-defined conversions. A conversion operator is a special kind of member function that converts a value of a class type to a value of some other type. A conversion function typically has the general form

1

operator type() const;

where type represents a type. Conversion operators can be defined for any type (other than void) that can be a function return type. Conversions to an array or a function type are not permitted. Conversions to pointer types—both data and function pointers—and to reference types are allowed.

Conversion operators have no explicitly stated return type and no parameters, and they must be defined as member functions. Conversion operations ordinarily should not change the object they are converting. As a result, conversion operators usually should be defined as const members.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

class SmallInt {
public:
    SmallInt(int i = 0): val(i)
    {
        if (i < 0 || i > 255)
            throw std::out_of_range("Bad SmallInt value");
    }
    operator int() const { return val; }
private:
    std::size_t val;
};

The conversion operator converts SmallInt objects to int:

1
2
3

SmallInt si;
si = 4; // implicitly converts 4 to SmallInt then calls SmallInt::operator=
si + 3; // implicitly converts si to int followed by integer addition

Although the compiler will apply only one user-defined conversion at a time, an implicit user-defined conversion can be preceded or followed by a standard (built-in) conversion. As a result, we can pass any arithmetic type to the SmallInt constructor.

1
2
3
4

// the double argument is converted to int using the built-in conversion
SmallInt si = 3.14; // calls the SmallInt(int) constructor
// the SmallInt conversion operator converts si to int;
si + 3.14; // that int is converted to double using the built-in conversion

Because conversion operators are implicitly applied, there is no way to pass arguments to these functions. Hence, conversion operators may not be defined to take parameters. Although a conversion function does not specify a return type, each conversion function must return a value of its corresponding type:

1
2
3
4
5
6
7
8
9

class SmallInt;
operator int(SmallInt&); // error: nonmember

class SmallInt {
public:
    int operator int() const; // error: return type
    operator int(int = 0) const; // error: parameter list
    operator int*() const { return 42; } // error: 42 is not a pointer
};

Conversion operators are misleading when there is no obvious single mapping between the class type and the conversion type. For example, consider a class that represents a Date. We might think it would be a good idea to provide a conversion from Date to int. Alternatively, the conversion operator might return an int representing the number of days that have elapsed since some epoch point, such as January 1, 1970. The problem is that there is no single one-to-one mapping between an object of type Date and a value of type int. In such cases, it is better not to define the conversion operator. Instead, the class ought to define one or more ordinary members to extract the information in these various forms.

explicit Conversion Operators

In practice, classes rarely provide conversion operators. It is not uncommon for classes to define conversions to bool.

1
2

int i = 42;
cin << i; // this code would be legal if the conversion to bool were not explicit!

This program attempts to use the output operator on an input stream. There is no « defined for istream, so the code is almost surely in error. However, this code could use the bool conversion operator to convert cin to bool. The resulting bool value would then be promoted to int and used as the left-hand operand to the built-in version of the left-shift operator. To prevent such problems, the new standard introduced explicit conversion operators:

1
2
3
4
5
6

class SmallInt {
public:
    // the compiler won't automatically apply this conversion
    explicit operator int() const { return val; }
    // other members as before
};

If the conversion operator is explicit, we can still do the conversion. However, with one exception, we must do so explicitly through a cast.

1
2
3

SmallInt si = 3; // ok: the SmallInt constructor is not explicit
si + 3; // error: implicit is conversion required, but operator int is explicit
static_cast<int>(si) + 3; // ok: explicitly request the conversion

The exception is that the compiler will apply an explicit conversion to an expression used as a condition. That is, an explicit conversion will be used implicitly to convert an expression used as

• The condition of an if, while, or do statement
• The condition expression in a for statement header
• An operand to the logical NOT (!), OR (||), or AND (&&) operators
• The condition expression in a conditional (?:) operator

Conversion to bool

Under the new standard, the IO library defines an explicit conversion to bool. Whenever we use a stream object in a condition, we use the operator bool that is defined for the IO types.

1

while (std::cin >> value)

The condition in the while executes the input operator, which reads into value and returns cin. To evaluate the condition, cin is implicitly converted by the istream operator bool conversion function. That function returns true if the condition state of cin is good, and false otherwise. Conversion to bool is usually intended for use in conditions. As a result, operator bool ordinarily should be defined as explicit.

Avoiding Ambiguous Conversions

If a class has one or more conversions, it is important to ensure that there is only one way to convert from the class type to the target type. If there is more than one way to perform a conversion, it will be hard to write unambiguous code. There are two ways that multiple conversion paths can occur. The first happens when two classes provide mutual conversions. For example, mutual conversions exist when a class A defines a converting constructor that takes an object of class B and B itself defines a conversion operator to type A. The second way to generate multiple conversion paths is to define multiple conversions from or to types that are themselves related by conversions. The most obvious instance is the built-in arithmetic types. A given class ordinarily ought to define at most one conversion to or from an arithmetic type. So, ordinarily it is a bad idea to define classes with mutual conversions or to define conversions to or from two arithmetic types.

In the following example, we’ve defined two ways to obtain an A from a B: either by using B’s conversion operator or by using the A constructor that takes a B:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

// usually a bad idea to have mutual conversions between two class types
struct B;
struct A {
    A() = default;
    A(const B&); // converts a B to an A
    // other members
};
struct B {
    operator A() const; // also converts a B to an A
    // other members
};
A f(const A&);
B b;
A a = f(b); // error ambiguous: f(B::operator A())
            // or f(A::A(const B&))

Because there are two ways to obtain an A from a B, the compiler doesn’t know which conversion to run; the call to f is ambiguous. If we want to make this call, we have to explicitly call the conversion operator or the constructor:

1
2

A a1 = f(b.operator A()); // ok: use B's conversion operator
A a2 = f(A(b)); // ok: use A's constructor

The following class has converting constructors from two different arithmetic types, and conversion operators to two different arithmetic types:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

struct A {
    A(int = 0); // usually a bad idea to have two
    A(double); // conversions from arithmetic types
    operator int() const; // usually a bad idea to have two
    operator double() const; // conversions to arithmetic types
    // other members
};
void f2(long double);
A a;
f2(a);  // error ambiguous: f(A::operator int())
        // or f(A::operator double())
long lg;
A a2(lg); // error ambiguous: A::A(int) or A::A(double)

In the call to f2, neither conversion is an exact match to long double. However, the call is ambiguous. We encounter the same problem when we try to initialize a2 from a long. Neither constructor is an exact match for long. The call to f2, and the initialization of a2, are ambiguous because the standard conversions that were needed had the same rank.

1
2
3

short s = 42;
// promoting short to int is better than converting short to double
A a3(s); // uses A::A(int)

When two user-defined conversions are used, the rank of the standard conversion, if any, preceding or following the conversion function is used to select the best match.

Overloaded Functions and Converting Constructors

Choosing among multiple conversions is further complicated when we call an overloaded function. If two or more conversions provide a viable match, then the conversions are considered equally good.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

struct C {
    C(int);
    // other members
};
struct D {
    D(int);
    // other members
};
void manip(const C&);
void manip(const D&);
manip(10); // error ambiguous: manip(C(10)) or manip(D(10))

Here both C and D have constructors that take an int. Hence, the call is ambiguous. The caller can disambiguate by explicitly constructing the correct type:

1

manip(C(10)); // ok: calls manip(const C&)

Needing to use a constructor or a cast to convert an argument in a call to an overloaded function frequently is a sign of bad design.

Overloaded Functions and User-Defined Conversion

In a call to an overloaded function, if two (or more) user-defined conversions provide a viable match, the conversions are considered equally good. The rank of any standard conversions that might or might not be required is not considered.

1
2
3
4
5
6
7
8

struct E {
    E(double);
    // other members
};
void manip2(const C&);
void manip2(const E&);
// error ambiguous: two different user-defined conversions could be used
manip2(10); // manip2(C(10) or manip2(E(double(10)))

In this case, C has a conversion from int and E has a conversion from double. For the call manip2(10), both manip2 functions are viable. Because calls to the overloaded functions require different user-defined conversions from one another, this call is ambiguous. In particular, even though one of the calls requires a standard conversion and the other is an exact match, the compiler will still flag this call as an error.

Function Matching and Overloaded Operators

Overloaded operators are overloaded functions. Normal function matching is used to determine which operator—built-in or overloaded—to apply to a given expression. However, when an operator function is used in an expression, the set of candidate functions is broader than when we call a function using the call operator. If a has a class type, the expression a sym b might be

1
2

a.operatorsym (b); // a has operatorsym as a member function
operatorsym(a, b); // operatorsym is an ordinary function

When a call is through an object of a class type (or through a reference or pointer to such an object), then only the member functions of that class are considered. When we use an overloaded operator in an expression, there is nothing to indicate whether we’re using a member or nonmember function. Therefore, the set of candidate functions for an operator used in an expression can contain both nonmember and member functions. As an example, we’ll define an addition operator for our SmallInt class:

1
2
3
4
5
6
7
8
9

class SmallInt {
    friend
    SmallInt operator+(const SmallInt&, const SmallInt&);
public:
    SmallInt(int = 0); // conversion from int
    operator int() const { return val; } // conversion to int
private:
    std::size_t val;
};

We can use this class to add two SmallInts, but we will run into ambiguity problems if we attempt to perform mixed-mode arithmetic:

1
2
3

SmallInt s1, s2;
SmallInt s3 = s1 + s2; // uses overloaded operator+
int i = s3 + 0; // error: ambiguous

The first addition uses the overloaded version of + that takes two SmallInt values. The second addition is ambiguous, because we can convert 0 to a SmallInt and use the SmallInt version of +, or convert s3 to int and use the built-in addition operator on ints. Providing both conversion functions to an arithmetic type and overloaded operators for the same class type may lead to ambiguities between the overloaded operators and the built-in operators.

Object-Oriented Programming

The key ideas in object-oriented programming are data abstraction, inheritance, and dynamic binding. Using data abstraction, we can define classes that separate interface from implementation. Through inheritance, we can define classes that model the relationships among similar types. Through dynamic binding, we can use objects of these types while ignoring the details of how they differ.

Inheritance

Classes related by inheritance form a hierarchy. Typically there is a base class at the root of the hierarchy, from which the other classes inherit, directly or indirectly. These inheriting classes are known as derived classes. The base class defines those members that are common to the types in the hierarchy. Each derived class defines those members that are specific to the derived class itself.

To model our different kinds of pricing strategies, we’ll define a class named Quote, which will be the base class of our hierarchy. A Quote object will represent undiscounted books. From Quote we will inherit a second class, named Bulk_quote, to represent books that can be sold with a quantity discount. In C++, a base class distinguishes functions that are type dependent from those that it expects its derived classes to inherit without change. The base class defines as virtual those functions it expects its derived classes to define for themselves.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

class Quote {
public:
    std::string isbn() const;
    virtual double net_price(std::size_t n) const;
};

// the derivation list, Bulk_quote inherits from Quote
class Bulk_quote : public Quote {
public:
    double net_price(std::size_t) const override;
};

Because Bulk_quote uses public in its derivation list, we can use objects of type Bulk_quote as if they were Quote objects. A derived class must include in its own class body a declaration of all the virtual functions it intends to define for itself. A derived class may include the virtual keyword on these functions but is not required to do so. The new standard lets a derived class explicitly note that it intends a member function to override a virtual that it inherits. It does so by specifying override after its parameter list.

Dynamic Binding

Through dynamic binding, we can use the same code to process objects of either type Quote or Bulk_quote interchangeably.

1
2
3
4
5
6
7
8
9

double print_total(ostream &os, const Quote &item, size_t n)
{
    // depending on the type of the object bound to the item parameter
    // calls either Quote::net_price or Bulk_quote::net_price
    double ret = item.net_price(n);
    os << "ISBN: " << item.isbn() // calls Quote::isbn
    << " # sold: " << n << " total due: " << ret << endl;
    return ret;
}

Because the parameter is a reference to Quote, we can call this function on either a Quote object or a Bulk_quote object. Because net_price is a virtual function, and because print_total calls net_price through a reference, the version of net_price that is run will depend on the type of the object that we pass to print_total:

1
2
3

// basic has type Quote; bulk has type Bulk_quote
print_total(cout, basic, 20); // calls Quote version of net_price
print_total(cout, bulk, 20); // calls Bulk_quote version of net_price

Because the decision as to which version to run depends on the type of the argument, that decision can’t be made until run time. Therefore, dynamic binding is sometimes known as run-time binding. In C++, dynamic binding happens when a virtual function is called through a reference (or a pointer) to a base class.

Defining a Base Class

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

class Quote {
public:
    Quote() = default;
    Quote(const std::string &book, double sales_price):
        bookNo(book), price(sales_price) { }
    std::string isbn() const { return bookNo; }
    // returns the total sales price for the specified number of items
    // derived classes will override and apply different discount algorithms
    virtual double net_price(std::size_t n) const
        { return n * price; }
    virtual ~Quote() = default; // dynamic binding for the destructor
private:
    std::string bookNo; // ISBN number of this item
protected:
    double price = 0.0; // normal, undiscounted price
};

Base classes ordinarily should define a virtual destructor. Virtual destructors are needed even if they do no work.

In C++, a base class must distinguish the functions it expects its derived classes to override from those that it expects its derived classes to inherit without change. The base class defines as virtual those functions it expects its derived classes to override. When we call a virtual function through a pointer or reference , the call will be dynamically bound. Any nonstatic member function, other than a constructor, may be virtual. The virtual keyword appears only on the declaration inside the class and may not be used on a function definition that appears outside the class body.

A derived class inherits the members defined in its base class. Like any other code that uses the base class, a derived class may access the public members of its base class but may not access the private members. However, sometimes a base class has members that it wants to let its derived classes use while still prohibiting access to those same members by other users. We specify such members after a protected access specifier.

Defining a Derived Class

1
2
3
4
5
6
7
8
9

class Bulk_quote : public Quote { // Bulk_quote inherits from Quote
    Bulk_quote() = default;
    Bulk_quote(const std::string&, double, std::size_t, double);
    //overrides the base version in order to implement the bulk purchase discount policy
    double net_price(std::size_t) const override;
private:
    std::size_t min_qty = 0; // minimum purchase for the discount to apply
    double discount = 0.0; // fractional discount to apply
};