C: Classes and class hierarchies

A class is a user-defined type, for which a programmer can define the representation, operations, and interfaces. Class hierarchies are used to organize related classes into hierarchical structures.

Class rule summary:

• (C.1: Organize related data into structures (structs or classes))
• (C.2: Use class if the class has an invariant; use struct if the data members can vary independently)
• (C.3: Represent the distinction between an interface and an implementation using a class)
• (C.4: Make a function a member only if it needs direct access to the representation of a class)
• (C.5: Place helper functions in the same namespace as the class they support)
• (C.7: Don't define a class or enum and declare a variable of its type in the same statement)
• (C.8: Use class rather than struct if any member is non-public)
• (C.9: Minimize exposure of members)

Subsections:

• (C.concrete: Concrete types)
• (C.ctor: Constructors, assignments, and destructors)
• (C.con: Containers and other resource handles)
• (C.lambdas: Function objects and lambdas)
• (C.hier: Class hierarchies (OOP))
• (C.over: Overloading and overloaded operators)
• (C.union: Unions)

C.1: Organize related data into structures (structs or classes)#

Reason#

Ease of comprehension. If data is related (for fundamental reasons), that fact should be reflected in code.

Example#

void draw(int x, int y, int x2, int y2);  // BAD: unnecessary implicit relationships
void draw(Point from, Point to);          // better

Note#

A simple class without virtual functions implies no space or time overhead.

Note#

From a language perspective class and struct differ only in the default visibility of their members.

Enforcement#

Probably impossible. Maybe a heuristic looking for data items used together is possible.

C.2: Use class if the class has an invariant; use struct if the data members can vary independently#

Reason#

Readability. Ease of comprehension. The use of class alerts the programmer to the need for an invariant. This is a useful convention.

Note#

An invariant is a logical condition for the members of an object that a constructor must establish for the public member functions to assume. After the invariant is established (typically by a constructor) every member function can be called for the object. An invariant can be stated informally (e.g., in a comment) or more formally using Expects.

If all data members can vary independently of each other, no invariant is possible.

Example#

struct Pair {  // the members can vary independently
    string name;
    int volume;
};

but:

class Date {
public:
    // validate that {yy, mm, dd} is a valid date and initialize
    Date(int yy, Month mm, char dd);
    // ...
private:
    int y;
    Month m;
    char d;    // day
};

Note#

If a class has any private data, a user cannot completely initialize an object without the use of a constructor. Hence, the class definer will provide a constructor and must specify its meaning. This effectively means the definer need to define an invariant.

See also:

• (define a class with private data as class)
• (Prefer to place the interface first in a class)
• (minimize exposure of members)
• (Avoid protected data)

Enforcement#

Look for structs with all data private and classes with public members.

C.3: Represent the distinction between an interface and an implementation using a class#

Reason#

An explicit distinction between interface and implementation improves readability and simplifies maintenance.

Example#

class Date {
public:
    Date();
    // validate that {yy, mm, dd} is a valid date and initialize
    Date(int yy, Month mm, char dd);
    int day() const;
    Month month() const;
    // ...
private:
    // ... some representation ...
};

For example, we can now change the representation of a Date without affecting its users (recompilation is likely, though).

Note#

Using a class in this way to represent the distinction between interface and implementation is of course not the only way. For example, we can use a set of declarations of freestanding functions in a namespace, an abstract base class, or a function template with concepts to represent an interface. The most important issue is to explicitly distinguish between an interface and its implementation "details." Ideally, and typically, an interface is far more stable than its implementation(s).

Enforcement#

???

C.4: Make a function a member only if it needs direct access to the representation of a class#

Reason#

Less coupling than with member functions, fewer functions that can cause trouble by modifying object state, reduces the number of functions that needs to be modified after a change in representation.

Example#

class Date {
    // ... relatively small interface ...
};
// helper functions:
Date next_weekday(Date);
bool operator==(Date, Date);

The "helper functions" have no need for direct access to the representation of a Date.

Note#

This rule becomes even better if C++ gets "uniform function call".

Exception#

The language requires virtual functions to be members, and not all virtual functions directly access data. In particular, members of an abstract class rarely do.

Note multi-methods.

Exception#

The language requires operators =, (), [], and -> to be members.

Exception#

An overload set could have some members that do not directly access private data:

class Foobar {
public:
    void foo(long x) { /* manipulate private data */ }
    void foo(double x) { foo(std::lround(x)); }
    // ...
private:
    // ...
};

Exception#

Similarly, a set of functions could be designed to be used in a chain:

x.scale(0.5).rotate(45).set_color(Color::red);

Typically, some but not all of such functions directly access private data.

Enforcement#

• Look for non-virtual member functions that do not touch data members directly. The snag is that many member functions that do not need to touch data members directly do.
• Ignore virtual functions.
• Ignore functions that are part of an overload set out of which at least one function accesses private members.
• Ignore functions returning this.

C.5: Place helper functions in the same namespace as the class they support#

Reason#

A helper function is a function (usually supplied by the writer of a class) that does not need direct access to the representation of the class, yet is seen as part of the useful interface to the class. Placing them in the same namespace as the class makes their relationship to the class obvious and allows them to be found by argument dependent lookup.

Example#

namespace Chrono { // here we keep time-related services
    class Time { /* ... */ };
    class Date { /* ... */ };
    // helper functions:
    bool operator==(Date, Date);
    Date next_weekday(Date);
    // ...
}

Note#

This is especially important for (overloaded operators).

Enforcement#

• Flag global functions taking argument types from a single namespace.

C.7: Don't define a class or enum and declare a variable of its type in the same statement#

Reason#

Mixing a type definition and the definition of another entity in the same declaration is confusing and unnecessary.

Example, bad#

struct Data { /*...*/ } data{ /*...*/ };

Example, good#

struct Data { /*...*/ };
Data data{ /*...*/ };

Enforcement#

• Flag if the } of a class or enumeration definition is not followed by a ;. The ; is missing.

C.8: Use class rather than struct if any member is non-public#

Reason#

Readability. To make it clear that something is being hidden/abstracted. This is a useful convention.

Example, bad#

struct Date {
    int d, m;
    Date(int i, Month m);
    // ... lots of functions ...
private:
    int y;  // year
};

There is nothing wrong with this code as far as the C++ language rules are concerned, but nearly everything is wrong from a design perspective. The private data is hidden far from the public data. The data is split in different parts of the class declaration. Different parts of the data have different access. All of this decreases readability and complicates maintenance.

Note#

Prefer to place the interface first in a class, (see NL.16).

Enforcement#

Flag classes declared with struct if there is a private or protected member.

C.9: Minimize exposure of members#

Reason#

Encapsulation. Information hiding. Minimize the chance of unintended access. This simplifies maintenance.

Example#

template<typename T, typename U>
struct pair {
    T a;
    U b;
    // ...
};

Whatever we do in the //-part, an arbitrary user of a pair can arbitrarily and independently change its a and b. In a large code base, we cannot easily find which code does what to the members of pair. This might be exactly what we want, but if we want to enforce a relation among members, we need to make them private and enforce that relation (invariant) through constructors and member functions. For example:

class Distance {
public:
    // ...
    double meters() const { return magnitude*unit; }
    void set_unit(double u)
    {
            // ... check that u is a factor of 10 ...
            // ... change magnitude appropriately ...
            unit = u;
    }
    // ...
private:
    double magnitude;
    double unit;    // 1 is meters, 1000 is kilometers, 0.001 is millimeters, etc.
};

Note#

If the set of direct users of a set of variables cannot be easily determined, the type or usage of that set cannot be (easily) changed/improved. For public and protected data, that's usually the case.

Example#

A class can provide two interfaces to its users. One for derived classes (protected) and one for general users (public). For example, a derived class might be allowed to skip a run-time check because it has already guaranteed correctness:

class Foo {
public:
    int bar(int x) { check(x); return do_bar(x); }
    // ...
protected:
    int do_bar(int x); // do some operation on the data
    // ...
private:
    // ... data ...
};
class Dir : public Foo {
    //...
    int mem(int x, int y)
    {
        /* ... do something ... */
        return do_bar(x + y); // OK: derived class can bypass check
    }
};
void user(Foo& x)
{
    int r1 = x.bar(1);      // OK, will check
    int r2 = x.do_bar(2);   // error: would bypass check
    // ...
}

Note#

(protected data is a bad idea).

Note#

Prefer the order public members before protected members before private members; see (NL.16).

Enforcement#

• (Flag protected data).
• Flag mixtures of public and private data

C.concrete: Concrete types#

Concrete type rule summary:

• (C.10: Prefer concrete types over class hierarchies)
• (C.11: Make concrete types regular)
• (C.12: Don't make data members const or references)

C.10: Prefer concrete types over class hierarchies#

Reason#

A concrete type is fundamentally simpler than a type in a class hierarchy: easier to design, easier to implement, easier to use, easier to reason about, smaller, and faster. You need a reason (use cases) for using a hierarchy.

Example#

class Point1 {
    int x, y;
    // ... operations ...
    // ... no virtual functions ...
};
class Point2 {
    int x, y;
    // ... operations, some virtual ...
    virtual ~Point2();
};
void use()
{
    Point1 p11 {1, 2};   // make an object on the stack
    Point1 p12 {p11};    // a copy
    auto p21 = make_unique<Point2>(1, 2);   // make an object on the free store
    auto p22 = p21->clone();                // make a copy
    // ...
}

If a class is part of a hierarchy, we (in real code if not necessarily in small examples) must manipulate its objects through pointers or references. That implies more memory overhead, more allocations and deallocations, and more run-time overhead to perform the resulting indirections.

Note#

Concrete types can be stack-allocated and be members of other classes.

Note#

The use of indirection is fundamental for run-time polymorphic interfaces. The allocation/deallocation overhead is not (that's just the most common case). We can use a base class as the interface of a scoped object of a derived class. This is done where dynamic allocation is prohibited (e.g. hard-real-time) and to provide a stable interface to some kinds of plug-ins.

Enforcement#

???

C.11: Make concrete types regular#

Reason#

Regular types are easier to understand and reason about than types that are not regular (irregularities requires extra effort to understand and use).

The C++ built-in types are regular, and so are standard-library classes such as string, vector, and map. Concrete classes without assignment and equality can be defined, but they are (and should be) rare.

Example#

struct Bundle {
    string name;
    vector<Record> vr;
};
bool operator==(const Bundle& a, const Bundle& b)
{
    return a.name == b.name && a.vr == b.vr;
}
Bundle b1 { "my bundle", {r1, r2, r3}};
Bundle b2 = b1;
if (!(b1 == b2)) error("impossible!");
b2.name = "the other bundle";
if (b1 == b2) error("No!");

In particular, if a concrete type is copyable, prefer to also give it an equality comparison operator, and ensure that a = b implies a == b.

Note#

For structs intended to be shared with C code, defining operator== may not be feasible.

Note#

Handles for resources that cannot be cloned, e.g., a scoped_lock for a mutex, are concrete types but typically cannot be copied (instead, they can usually be moved), so they can't be regular; instead, they tend to be move-only.

Enforcement#

???

C.12: Don't make data members const or references#

Reason#

They are not useful, and make types difficult to use by making them either uncopyable or partially uncopyable for subtle reasons.

Example; bad#

class bad {
    const int i;    // bad
    string& s;      // bad
    // ...
};

The const and & data members make this class "only-sort-of-copyable" -- copy-constructible but not copy-assignable.

Note#

If you need a member to point to something, use a pointer (raw or smart, and gsl::not_null if it should not be null) instead of a reference.

Enforcement#

Flag a data member that is const, &, or &&.

C.ctor: Constructors, assignments, and destructors#

These functions control the lifecycle of objects: creation, copy, move, and destruction. Define constructors to guarantee and simplify initialization of classes.

These are default operations:

• a default constructor: X()
• a copy constructor: X(const X&)
• a copy assignment: operator=(const X&)
• a move constructor: X(X&&)
• a move assignment: operator=(X&&)
• a destructor: ~X()

By default, the compiler defines each of these operations if it is used, but the default can be suppressed.

The default operations are a set of related operations that together implement the lifecycle semantics of an object. By default, C++ treats classes as value-like types, but not all types are value-like.

Set of default operations rules:

• (C.20: If you can avoid defining any default operations, do)
• (C.21: If you define or =delete any copy, move, or destructor function, define or =delete them all)
• (C.22: Make default operations consistent)

Destructor rules:

• (C.30: Define a destructor if a class needs an explicit action at object destruction)
• (C.31: All resources acquired by a class must be released by the class's destructor)
• (C.32: If a class has a raw pointer (T*) or reference (T&), consider whether it might be owning)
• (C.33: If a class has an owning pointer member, define a destructor)
• (C.35: A base class destructor should be either public and virtual, or protected and non-virtual)
• (C.36: A destructor must not fail)
• (C.37: Make destructors noexcept)

Constructor rules:

• (C.40: Define a constructor if a class has an invariant)
• (C.41: A constructor should create a fully initialized object)
• (C.42: If a constructor cannot construct a valid object, throw an exception)
• (C.43: Ensure that a copyable class has a default constructor)
• (C.44: Prefer default constructors to be simple and non-throwing)
• (C.45: Don't define a default constructor that only initializes data members; use member initializers instead)
• (C.46: By default, declare single-argument constructors explicit)
• (C.47: Define and initialize member variables in the order of member declaration)
• (C.48: Prefer in-class initializers to member initializers in constructors for constant initializers)
• (C.49: Prefer initialization to assignment in constructors)
• (C.50: Use a factory function if you need "virtual behavior" during initialization)
• (C.51: Use delegating constructors to represent common actions for all constructors of a class)
• (C.52: Use inheriting constructors to import constructors into a derived class that does not need further explicit initialization)

Copy and move rules:

• (C.60: Make copy assignment non-virtual, take the parameter by const&, and return by non-const&)
• (C.61: A copy operation should copy)
• (C.62: Make copy assignment safe for self-assignment)
• (C.63: Make move assignment non-virtual, take the parameter by &&, and return by non-const&)
• (C.64: A move operation should move and leave its source in a valid state)
• (C.65: Make move assignment safe for self-assignment)
• (C.66: Make move operations noexcept)
• (C.67: A polymorphic class should suppress public copy/move)

Other default operations rules:

• (C.80: Use =default if you have to be explicit about using the default semantics)
• (C.81: Use =delete when you want to disable default behavior (without wanting an alternative))
• (C.82: Don't call virtual functions in constructors and destructors)
• (C.83: For value-like types, consider providing a noexcept swap function)
• (C.84: A swap must not fail)
• (C.85: Make swap noexcept)
• (C.86: Make == symmetric with respect of operand types and noexcept)
• (C.87: Beware of == on base classes)
• (C.89: Make a hash noexcept)
• (C.90: Rely on constructors and assignment operators, not memset and memcpy)

C.defop: Default Operations#

By default, the language supplies the default operations with their default semantics. However, a programmer can disable or replace these defaults.

C.20: If you can avoid defining default operations, do#

Reason#

It's the simplest and gives the cleanest semantics.

Example#

struct Named_map {
public:
    // ... no default operations declared ...
private:
    string name;
    map<int, int> rep;
};
Named_map nm;        // default construct
Named_map nm2 {nm};  // copy construct

Since std::map and string have all the special functions, no further work is needed.

Note#

This is known as "the rule of zero".

Enforcement#

(Not enforceable) While not enforceable, a good static analyzer can detect patterns that indicate a possible improvement to meet this rule. For example, a class with a (pointer, size) pair of member and a destructor that deletes the pointer could probably be converted to a vector.

C.21: If you define or =delete any copy, move, or destructor function, define or =delete them all#

Reason#

The semantics of copy, move, and destruction are closely related, so if one needs to be declared, the odds are that others need consideration too.

Declaring any copy/move/destructor function, even as =default or =delete, will suppress the implicit declaration of a move constructor and move assignment operator. Declaring a move constructor or move assignment operator, even as =default or =delete, will cause an implicitly generated copy constructor or implicitly generated copy assignment operator to be defined as deleted. So as soon as any of these are declared, the others should all be declared to avoid unwanted effects like turning all potential moves into more expensive copies, or making a class move-only.

Example, bad#

struct M2 {   // bad: incomplete set of copy/move/destructor operations
public:
    // ...
    // ... no copy or move operations ...
    ~M2() { delete[] rep; }
private:
    pair<int, int>* rep;  // zero-terminated set of pairs
};
void use()
{
    M2 x;
    M2 y;
    // ...
    x = y;   // the default assignment
    // ...
}

Given that "special attention" was needed for the destructor (here, to deallocate), the likelihood that the implicitly-defined copy and move assignment operators will be correct is low (here, we would get double deletion).

Note#

This is known as "the rule of five."

Note#

If you want a default implementation (while defining another), write =default to show you're doing so intentionally for that function. If you don't want a generated default function, suppress it with =delete.

Example, good#

When a destructor needs to be declared just to make it virtual, it can be defined as defaulted.

class AbstractBase {
public:
    virtual ~AbstractBase() = default;
    // ...
};

To prevent slicing as per (C.67), make the copy and move operations protected or =deleted, and add a clone:

class ClonableBase {
public:
    virtual unique_ptr<ClonableBase> clone() const;
    virtual ~ClonableBase() = default;
    CloneableBase() = default;
    ClonableBase(const ClonableBase&) = delete;
    ClonableBase& operator=(const ClonableBase&) = delete;
    ClonableBase(ClonableBase&&) = delete;
    ClonableBase& operator=(ClonableBase&&) = delete;
    // ... other constructors and functions ...
};

Defining only the move operations or only the copy operations would have the same effect here, but stating the intent explicitly for each special member makes it more obvious to the reader.

Note#

Compilers enforce much of this rule and ideally warn about any violation.

Note#

Relying on an implicitly generated copy operation in a class with a destructor is deprecated.

Note#

Writing these functions can be error prone. Note their argument types:

class X {
public:
    // ...
    virtual ~X() = default;            // destructor (virtual if X is meant to be a base class)
    X(const X&) = default;             // copy constructor
    X& operator=(const X&) = default;  // copy assignment
    X(X&&) = default;                  // move constructor
    X& operator=(X&&) = default;       // move assignment
};

A minor mistake (such as a misspelling, leaving out a const, using & instead of &&, or leaving out a special function) can lead to errors or warnings. To avoid the tedium and the possibility of errors, try to follow the (rule of zero).

Enforcement#

(Simple) A class should have a declaration (even a =delete one) for either all or none of the copy/move/destructor functions.

C.22: Make default operations consistent#

Reason#

The default operations are conceptually a matched set. Their semantics are interrelated. Users will be surprised if copy/move construction and copy/move assignment do logically different things. Users will be surprised if constructors and destructors do not provide a consistent view of resource management. Users will be surprised if copy and move don't reflect the way constructors and destructors work.

Example, bad#

class Silly {   // BAD: Inconsistent copy operations
    class Impl {
        // ...
    };
    shared_ptr<Impl> p;
public:
    Silly(const Silly& a) : p(make_shared<Impl>()) { *p = *a.p; }   // deep copy
    Silly& operator=(const Silly& a) { p = a.p; }   // shallow copy
    // ...
};

These operations disagree about copy semantics. This will lead to confusion and bugs.

Enforcement#

• (Complex) A copy/move constructor and the corresponding copy/move assignment operator should write to the same member variables at the same level of dereference.
• (Complex) Any member variables written in a copy/move constructor should also be initialized by all other constructors.
• (Complex) If a copy/move constructor performs a deep copy of a member variable, then the destructor should modify the member variable.
• (Complex) If a destructor is modifying a member variable, that member variable should be written in any copy/move constructors or assignment operators.

C.dtor: Destructors#

"Does this class need a destructor?" is a surprisingly insightful design question. For most classes the answer is "no" either because the class holds no resources or because destruction is handled by (the rule of zero); that is, its members can take care of themselves as concerns destruction. If the answer is "yes", much of the design of the class follows (see (the rule of five)).

C.30: Define a destructor if a class needs an explicit action at object destruction#

Reason#

A destructor is implicitly invoked at the end of an object's lifetime. If the default destructor is sufficient, use it. Only define a non-default destructor if a class needs to execute code that is not already part of its members' destructors.

Example#

template<typename A>
struct final_action {   // slightly simplified
    A act;
    final_action(A a) : act{a} {}
    ~final_action() { act(); }
};
template<typename A>
final_action<A> finally(A act)   // deduce action type
{
    return final_action<A>{act};
}
void test()
{
    auto act = finally([] { cout << "Exit test\n"; });  // establish exit action
    // ...
    if (something) return;   // act done here
    // ...
} // act done here

The whole purpose of final_action is to get a piece of code (usually a lambda) executed upon destruction.

Note#

There are two general categories of classes that need a user-defined destructor:

• A class with a resource that is not already represented as a class with a destructor, e.g., a vector or a transaction class.
• A class that exists primarily to execute an action upon destruction, such as a tracer or final_action.

Example, bad#

class Foo {   // bad; use the default destructor
public:
    // ...
    ~Foo() { s = ""; i = 0; vi.clear(); }  // clean up
private:
    string s;
    int i;
    vector<int> vi;
};

The default destructor does it better, more efficiently, and can't get it wrong.

Note#

If the default destructor is needed, but its generation has been suppressed (e.g., by defining a move constructor), use =default.

Enforcement#

Look for likely "implicit resources", such as pointers and references. Look for classes with destructors even though all their data members have destructors.

C.31: All resources acquired by a class must be released by the class's destructor#

Reason#

Prevention of resource leaks, especially in error cases.

Note#

For resources represented as classes with a complete set of default operations, this happens automatically.

Example#

class X {
    ifstream f;   // might own a file
    // ... no default operations defined or =deleted ...
};

X's ifstream implicitly closes any file it might have open upon destruction of its X.

Example, bad#

class X2 {     // bad
    FILE* f;   // might own a file
    // ... no default operations defined or =deleted ...
};

X2 might leak a file handle.

Note#

What about a socket that won't close? A destructor, close, or cleanup operation (should never fail). If it does nevertheless, we have a problem that has no really good solution. For starters, the writer of a destructor does not know why the destructor is called and cannot "refuse to act" by throwing an exception. See (discussion). To make the problem worse, many "close/release" operations are not retryable. Many have tried to solve this problem, but no general solution is known. If at all possible, consider failure to close/cleanup a fundamental design error and terminate.

Note#

A class can hold pointers and references to objects that it does not own. Obviously, such objects should not be deleted by the class's destructor. For example:

Preprocessor pp { /* ... */ };
Parser p { pp, /* ... */ };
Type_checker tc { p, /* ... */ };

Here p refers to pp but does not own it.

Enforcement#

• (Simple) If a class has pointer or reference member variables that are owners (e.g., deemed owners by using gsl::owner), then they should be referenced in its destructor.
• (Hard) Determine if pointer or reference member variables are owners when there is no explicit statement of ownership (e.g., look into the constructors).

C.32: If a class has a raw pointer (T*) or reference (T&), consider whether it might be owning#

Reason#

There is a lot of code that is non-specific about ownership.

Example#

class legacy_class
{
    foo* m_owning;   // Bad: change to unique_ptr<T> or owner<T*>
    bar* m_observer; // OK: keep
}

The only way to determine ownership may be code analysis.

Note#

Ownership should be clear in new code (and refactored legacy code) according to (R.20) for owning pointers and ((R.3) for non-owning pointers. References should never own R.4).

Enforcement#

Look at the initialization of raw member pointers and member references and see if an allocation is used.

C.33: If a class has an owning pointer member, define a destructor#

Reason#

An owned object must be deleted upon destruction of the object that owns it.

Example#

A pointer member could represent a resource. (A T* should not do so), but in older code, that's common. Consider a T* a possible owner and therefore suspect.

template<typename T>
class Smart_ptr {
    T* p;   // BAD: vague about ownership of *p
    // ...
public:
    // ... no user-defined default operations ...
};
void use(Smart_ptr<int> p1)
{
    // error: p2.p leaked (if not nullptr and not owned by some other code)
    auto p2 = p1;
}

Note that if you define a destructor, you must define or delete (all default operations):

template<typename T>
class Smart_ptr2 {
    T* p;   // BAD: vague about ownership of *p
    // ...
public:
    // ... no user-defined copy operations ...
    ~Smart_ptr2() { delete p; }  // p is an owner!
};
void use(Smart_ptr2<int> p1)
{
    auto p2 = p1;   // error: double deletion
}

The default copy operation will just copy the p1.p into p2.p leading to a double destruction of p1.p. Be explicit about ownership:

template<typename T>
class Smart_ptr3 {
    owner<T*> p;   // OK: explicit about ownership of *p
    // ...
public:
    // ...
    // ... copy and move operations ...
    ~Smart_ptr3() { delete p; }
};
void use(Smart_ptr3<int> p1)
{
    auto p2 = p1;   // OK: no double deletion
}

Note#

Often the simplest way to get a destructor is to replace the pointer with a smart pointer (e.g., std::unique_ptr) and let the compiler arrange for proper destruction to be done implicitly.

Note#

Why not just require all owning pointers to be "smart pointers"? That would sometimes require non-trivial code changes and might affect ABIs.

Enforcement#

• A class with a pointer data member is suspect.
• A class with an owner<T> should define its default operations.

C.35: A base class destructor should be either public and virtual, or protected and non-virtual#

Reason#

To prevent undefined behavior. If the destructor is public, then calling code can attempt to destroy a derived class object through a base class pointer, and the result is undefined if the base class's destructor is non-virtual. If the destructor is protected, then calling code cannot destroy through a base class pointer and the destructor does not need to be virtual; it does need to be protected, not private, so that derived destructors can invoke it. In general, the writer of a base class does not know the appropriate action to be done upon destruction.

Discussion#

See (this in the Discussion section).

Example, bad#

struct Base {  // BAD: implicitly has a public non-virtual destructor
    virtual void f();
};
struct D : Base {
    string s {"a resource needing cleanup"};
    ~D() { /* ... do some cleanup ... */ }
    // ...
};
void use()
{
    unique_ptr<Base> p = make_unique<D>();
    // ...
} // p's destruction calls ~Base(), not ~D(), which leaks D::s and possibly more

Note#

A virtual function defines an interface to derived classes that can be used without looking at the derived classes. If the interface allows destroying, it should be safe to do so.

Note#

A destructor must be non-private or it will prevent using the type:

class X {
    ~X();   // private destructor
    // ...
};
void use()
{
    X a;                        // error: cannot destroy
    auto p = make_unique<X>();  // error: cannot destroy
}

Exception#

We can imagine one case where you could want a protected virtual destructor: When an object of a derived type (and only of such a type) should be allowed to destroy another object (not itself) through a pointer to base. We haven't seen such a case in practice, though.

Enforcement#

• A class with any virtual functions should have a destructor that is either public and virtual or else protected and non-virtual.
• If a class inherits publicly from a base class, the base class should have a destructor that is either public and virtual or else protected and non-virtual.

C.36: A destructor must not fail#

Reason#

In general we do not know how to write error-free code if a destructor should fail. The standard library requires that all classes it deals with have destructors that do not exit by throwing.

Example#

class X {
public:
    ~X() noexcept;
    // ...
};
X::~X() noexcept
{
    // ...
    if (cannot_release_a_resource) terminate();
    // ...
}

Note#

Many have tried to devise a fool-proof scheme for dealing with failure in destructors. None have succeeded to come up with a general scheme. This can be a real practical problem: For example, what about a socket that won't close? The writer of a destructor does not know why the destructor is called and cannot "refuse to act" by throwing an exception. See (discussion). To make the problem worse, many "close/release" operations are not retryable. If at all possible, consider failure to close/cleanup a fundamental design error and terminate.

Note#

Declare a destructor noexcept. That will ensure that it either completes normally or terminates the program.

Note#

If a resource cannot be released and the program must not fail, try to signal the failure to the rest of the system somehow (maybe even by modifying some global state and hope something will notice and be able to take care of the problem). Be fully aware that this technique is special-purpose and error-prone. Consider the "my connection will not close" example. Probably there is a problem at the other end of the connection and only a piece of code responsible for both ends of the connection can properly handle the problem. The destructor could send a message (somehow) to the responsible part of the system, consider that to have closed the connection, and return normally.

Note#

If a destructor uses operations that could fail, it can catch exceptions and in some cases still complete successfully (e.g., by using a different clean-up mechanism from the one that threw an exception).

Enforcement#

(Simple) A destructor should be declared noexcept if it could throw.

C.37: Make destructors noexcept#

Reason#

(A destructor must not fail). If a destructor tries to exit with an exception, it's a bad design error and the program had better terminate.

Note#

A destructor (either user-defined or compiler-generated) is implicitly declared noexcept (independently of what code is in its body) if all of the members of its class have noexcept destructors. By explicitly marking destructors noexcept, an author guards against the destructor becoming implicitly noexcept(false) through the addition or modification of a class member.

Example#

Not all destructors are noexcept by default; one throwing member poisons the whole class hierarchy

struct X {
    Details x;  // happens to have a throwing destructor
    // ...
    ~X() { }    // implicitly noexcept(false); aka can throw
};

So, if in doubt, declare a destructor noexcept.

Note#

Why not then declare all destructors noexcept? Because that would in many cases -- especially simple cases -- be distracting clutter.

Enforcement#

(Simple) A destructor should be declared noexcept if it could throw.

C.ctor: Constructors#

A constructor defines how an object is initialized (constructed).

C.40: Define a constructor if a class has an invariant#

Reason#

That's what constructors are for.

Example#

class Date {  // a Date represents a valid date
              // in the January 1, 1900 to December 31, 2100 range
    Date(int dd, int mm, int yy)
        :d{dd}, m{mm}, y{yy}
    {
        if (!is_valid(d, m, y)) throw Bad_date{};  // enforce invariant
    }
    // ...
private:
    int d, m, y;
};

It is often a good idea to express the invariant as an Ensures on the constructor.

Note#

A constructor can be used for convenience even if a class does not have an invariant. For example:

struct Rec {
    string s;
    int i {0};
    Rec(const string& ss) : s{ss} {}
    Rec(int ii) :i{ii} {}
};
Rec r1 {7};
Rec r2 {"Foo bar"};

Note#

The C++11 initializer list rule eliminates the need for many constructors. For example:

struct Rec2{
    string s;
    int i;
    Rec2(const string& ss, int ii = 0) :s{ss}, i{ii} {}   // redundant
};
Rec2 r1 {"Foo", 7};
Rec2 r2 {"Bar"};

The Rec2 constructor is redundant. Also, the default for int would be better done as a (member initializer).

See also: ((construct valid object) and constructor throws).

Enforcement#

• Flag classes with user-defined copy operations but no constructor (a user-defined copy is a good indicator that the class has an invariant)

C.41: A constructor should create a fully initialized object#

Reason#

A constructor establishes the invariant for a class. A user of a class should be able to assume that a constructed object is usable.

Example, bad#

class X1 {
    FILE* f;   // call init() before any other function
    // ...
public:
    X1() {}
    void init();   // initialize f
    void read();   // read from f
    // ...
};
void f()
{
    X1 file;
    file.read();   // crash or bad read!
    // ...
    file.init();   // too late
    // ...
}

Compilers do not read comments.

Exception#

If a valid object cannot conveniently be constructed by a constructor, (use a factory function).

Enforcement#

• (Simple) Every constructor should initialize every member variable (either explicitly, via a delegating ctor call or via default construction).
• (Unknown) If a constructor has an Ensures contract, try to see if it holds as a postcondition.

Note#

If a constructor acquires a resource (to create a valid object), that resource should be (released by the destructor). The idiom of having constructors acquire resources and destructors release them is called (RAII) ("Resource Acquisition Is Initialization").

C.42: If a constructor cannot construct a valid object, throw an exception#

Reason#

Leaving behind an invalid object is asking for trouble.

Example#

class X2 {
    FILE* f;
    // ...
public:
    X2(const string& name)
        :f{fopen(name.c_str(), "r")}
    {
        if (!f) throw runtime_error{"could not open" + name};
        // ...
    }
    void read();      // read from f
    // ...
};
void f()
{
    X2 file {"Zeno"}; // throws if file isn't open
    file.read();      // fine
    // ...
}

Example, bad#

class X3 {     // bad: the constructor leaves a non-valid object behind
    FILE* f;   // call is_valid() before any other function
    bool valid;
    // ...
public:
    X3(const string& name)
        :f{fopen(name.c_str(), "r")}, valid{false}
    {
        if (f) valid = true;
        // ...
    }
    bool is_valid() { return valid; }
    void read();   // read from f
    // ...
};
void f()
{
    X3 file {"Heraclides"};
    file.read();   // crash or bad read!
    // ...
    if (file.is_valid()) {
        file.read();
        // ...
    }
    else {
        // ... handle error ...
    }
    // ...
}

Note#

For a variable definition (e.g., on the stack or as a member of another object) there is no explicit function call from which an error code could be returned. Leaving behind an invalid object and relying on users to consistently check an is_valid() function before use is tedious, error-prone, and inefficient.

Exception#

There are domains, such as some hard-real-time systems (think airplane controls) where (without additional tool support) exception handling is not sufficiently predictable from a timing perspective. There the is_valid() technique must be used. In such cases, check is_valid() consistently and immediately to simulate (RAII).

Alternative#

If you feel tempted to use some "post-constructor initialization" or "two-stage initialization" idiom, try not to do that. If you really have to, look at (factory functions).

Note#

One reason people have used init() functions rather than doing the initialization work in a constructor has been to avoid code replication. ((Delegating constructors) and default member initialization) do that better. Another reason has been to delay initialization until an object is needed; the solution to that is often (not to declare a variable until it can be properly initialized)

Enforcement#

???

C.43: Ensure that a copyable class has a default constructor#

Reason#

That is, ensure that if a concrete class is copyable it also satisfies the rest of "semiregular."

Many language and library facilities rely on default constructors to initialize their elements, e.g. T a[10] and std::vector<T> v(10). A default constructor often simplifies the task of defining a suitable moved-from state for a type that is also copyable.

Example#

class Date { // BAD: no default constructor
public:
    Date(int dd, int mm, int yyyy);
    // ...
};
vector<Date> vd1(1000);   // default Date needed here
vector<Date> vd2(1000, Date{Month::October, 7, 1885});   // alternative

The default constructor is only auto-generated if there is no user-declared constructor, hence it's impossible to initialize the vector vd1 in the example above. The absence of a default value can cause surprises for users and complicate its use, so if one can be reasonably defined, it should be.

Date is chosen to encourage thought: There is no "natural" default date (the big bang is too far back in time to be useful for most people), so this example is non-trivial. {0, 0, 0} is not a valid date in most calendar systems, so choosing that would be introducing something like floating-point's NaN. However, most realistic Date classes have a "first date" (e.g. January 1, 1970 is popular), so making that the default is usually trivial.

class Date {
public:
    Date(int dd, int mm, int yyyy);
    Date() = default; // [(See also)](/class#Rc-default)
    // ...
private:
    int dd = 1;
    int mm = 1;
    int yyyy = 1970;
    // ...
};
vector<Date> vd1(1000);

Note#

A class with members that all have default constructors implicitly gets a default constructor:

struct X {
    string s;
    vector<int> v;
};
X x; // means X{{}, {}}; that is the empty string and the empty vector

Beware that built-in types are not properly default constructed:

struct X {
    string s;
    int i;
};
void f()
{
    X x;    // x.s is initialized to the empty string; x.i is uninitialized
    cout << x.s << ' ' << x.i << '\n';
    ++x.i;
}

Statically allocated objects of built-in types are by default initialized to 0, but local built-in variables are not. Beware that your compiler might default initialize local built-in variables, whereas an optimized build will not. Thus, code like the example above might appear to work, but it relies on undefined behavior. Assuming that you want initialization, an explicit default initialization can help:

struct X {
    string s;
    int i {};   // default initialize (to 0)
};

Notes#

Classes that don't have a reasonable default construction are usually not copyable either, so they don't fall under this guideline.

For example, a base class should not be copyable, and so does not necessarily need a default constructor:

// Shape is an abstract base class, not a copyable type.
// It might or might not need a default constructor.
struct Shape {
    virtual void draw() = 0;
    virtual void rotate(int) = 0;
    // =delete copy/move functions
    // ...
};

A class that must acquire a caller-provided resource during construction often cannot have a default constructor, but it does not fall under this guideline because such a class is usually not copyable anyway:

// std::lock_guard is not a copyable type.
// It does not have a default constructor.
lock_guard g {mx};  // guard the mutex mx
lock_guard g2;      // error: guarding nothing

A class that has a "special state" that must be handled separately from other states by member functions or users causes extra work (and most likely more errors). Such a type can naturally use the special state as a default constructed value, whether or not it is copyable:

// std::ofstream is not a copyable type.
// It does happen to have a default constructor
// that goes along with a special "not open" state.
ofstream out {"Foobar"};
// ...
out << log(time, transaction);

Similar special-state types that are copyable, such as copyable smart pointers that have the special state "==nullptr", should use the special state as their default constructed value.

However, it is preferable to have a default constructor default to a meaningful state such as std::strings "" and std::vectors {}.

Enforcement#

• Flag classes that are copyable by = without a default constructor
• Flag classes that are comparable with == but not copyable

C.44: Prefer default constructors to be simple and non-throwing#

Reason#

Being able to set a value to "the default" without operations that might fail simplifies error handling and reasoning about move operations.

Example, problematic#

template<typename T>
// elem points to space-elem element allocated using new
class Vector0 {
public:
    Vector0() :Vector0{0} {}
    Vector0(int n) :elem{new T[n]}, space{elem + n}, last{elem} {}
    // ...
private:
    own<T*> elem;
    T* space;
    T* last;
};

This is nice and general, but setting a Vector0 to empty after an error involves an allocation, which might fail. Also, having a default Vector represented as {new T[0], 0, 0} seems wasteful. For example, Vector0<int> v[100] costs 100 allocations.

Example#

template<typename T>
// elem is nullptr or elem points to space-elem element allocated using new
class Vector1 {
public:
    // sets the representation to {nullptr, nullptr, nullptr}; doesn't throw
    Vector1() noexcept {}
    Vector1(int n) :elem{new T[n]}, space{elem + n}, last{elem} {}
    // ...
private:
    own<T*> elem = nullptr;
    T* space = nullptr;
    T* last = nullptr;
};

Using {nullptr, nullptr, nullptr} makes Vector1{} cheap, but a special case and implies run-time checks. Setting a Vector1 to empty after detecting an error is trivial.

Enforcement#

• Flag throwing default constructors

C.45: Don't define a default constructor that only initializes data members; use in-class member initializers instead#

Reason#

Using in-class member initializers lets the compiler generate the function for you. The compiler-generated function can be more efficient.

Example, bad#

class X1 { // BAD: doesn't use member initializers
    string s;
    int i;
public:
    X1() :s{"default"}, i{1} { }
    // ...
};

Example#

class X2 {
    string s = "default";
    int i = 1;
public:
    // use compiler-generated default constructor
    // ...
};

Enforcement#

(Simple) A default constructor should do more than just initialize member variables with constants.

C.46: By default, declare single-argument constructors explicit#

Reason#

To avoid unintended conversions.

Example, bad#

class String {
public:
    String(int);   // BAD
    // ...
};
String s = 10;   // surprise: string of size 10

Exception#

If you really want an implicit conversion from the constructor argument type to the class type, don't use explicit:

class Complex {
public:
    Complex(double d);   // OK: we want a conversion from d to {d, 0}
    // ...
};
Complex z = 10.7;   // unsurprising conversion

See also: (Discussion of implicit conversions)

Note#

Copy and move constructors should not be made explicit because they do not perform conversions. Explicit copy/move constructors make passing and returning by value difficult.

Enforcement#

(Simple) Single-argument constructors should be declared explicit. Good single argument non-explicit constructors are rare in most code bases. Warn for all that are not on a "positive list".

C.47: Define and initialize member variables in the order of member declaration#

Reason#

To minimize confusion and errors. That is the order in which the initialization happens (independent of the order of member initializers).

Example, bad#

class Foo {
    int m1;
    int m2;
public:
    Foo(int x) :m2{x}, m1{++x} { }   // BAD: misleading initializer order
    // ...
};
Foo x(1); // surprise: x.m1 == x.m2 == 2

Enforcement#

(Simple) A member initializer list should mention the members in the same order they are declared.

See also: (Discussion)

C.48: Prefer in-class initializers to member initializers in constructors for constant initializers#

Reason#

Makes it explicit that the same value is expected to be used in all constructors. Avoids repetition. Avoids maintenance problems. It leads to the shortest and most efficient code.

Example, bad#

class X {   // BAD
    int i;
    string s;
    int j;
public:
    X() :i{666}, s{"qqq"} { }   // j is uninitialized
    X(int ii) :i{ii} {}         // s is "" and j is uninitialized
    // ...
};

How would a maintainer know whether j was deliberately uninitialized (probably a bad idea anyway) and whether it was intentional to give s the default value "" in one case and qqq in another (almost certainly a bug)? The problem with j (forgetting to initialize a member) often happens when a new member is added to an existing class.

Example#

class X2 {
    int i {666};
    string s {"qqq"};
    int j {0};
public:
    X2() = default;        // all members are initialized to their defaults
    X2(int ii) :i{ii} {}   // s and j initialized to their defaults
    // ...
};

Alternative: We can get part of the benefits from default arguments to constructors, and that is not uncommon in older code. However, that is less explicit, causes more arguments to be passed, and is repetitive when there is more than one constructor:

class X3 {   // BAD: inexplicit, argument passing overhead
    int i;
    string s;
    int j;
public:
    X3(int ii = 666, const string& ss = "qqq", int jj = 0)
        :i{ii}, s{ss}, j{jj} { }   // all members are initialized to their defaults
    // ...
};

Enforcement#

• (Simple) Every constructor should initialize every member variable (either explicitly, via a delegating ctor call or via default construction).
• (Simple) Default arguments to constructors suggest an in-class initializer might be more appropriate.

C.49: Prefer initialization to assignment in constructors#

Reason#

An initialization explicitly states that initialization, rather than assignment, is done and can be more elegant and efficient. Prevents "use before set" errors.

Example, good#

class A {   // Good
    string s1;
public:
    A(czstring p) : s1{p} { }    // GOOD: directly construct (and the C-string is explicitly named)
    // ...
};

Example, bad#

class B {   // BAD
    string s1;
public:
    B(const char* p) { s1 = p; }   // BAD: default constructor followed by assignment
    // ...
};
class C {   // UGLY, aka very bad
    int* p;
public:
    C() { cout << *p; p = new int{10}; }   // accidental use before initialized
    // ...
};

Example, better still#

Instead of those const char*s we could use C++17 std::string_view or gsl::span<char> as (a more general way to present arguments to a function):

class D {   // Good
    string s1;
public:
    D(string_view v) : s1{v} { }    // GOOD: directly construct
    // ...
};

C.50: Use a factory function if you need "virtual behavior" during initialization#

Reason#

If the state of a base class object must depend on the state of a derived part of the object, we need to use a virtual function (or equivalent) while minimizing the window of opportunity to misuse an imperfectly constructed object.

Note#

The return type of the factory should normally be unique_ptr by default; if some uses are shared, the caller can move the unique_ptr into a shared_ptr. However, if the factory author knows that all uses of the returned object will be shared uses, return shared_ptr and use make_shared in the body to save an allocation.

Example, bad#

class B {
public:
    B()
    {
        /* ... */
        f(); // BAD: C.82: Don't call virtual functions in constructors and destructors
        /* ... */
    }
    virtual void f() = 0;
};

Example#

class B {
protected:
    class Token {};
public:
    explicit B(Token) { /* ... */ }  // create an imperfectly initialized object
    virtual void f() = 0;
    template<class T>
    static shared_ptr<T> create()    // interface for creating shared objects
    {
        auto p = make_shared<T>(typename T::Token{});
        p->post_initialize();
        return p;
    }
protected:
    virtual void post_initialize()   // called right after construction
        { /* ... */ f(); /* ... */ } // GOOD: virtual dispatch is safe
};
class D : public B {                 // some derived class
protected:
    class Token {};
public:
    explicit D(Token) : B{ B::Token{} } {}
    void f() override { /* ...  */ };
protected:
    template<class T>
    friend shared_ptr<T> B::create();
};
shared_ptr<D> p = D::create<D>();  // creating a D object

make_shared requires that the constructor is public. By requiring a protected Token the constructor cannot be publicly called anymore, so we avoid an incompletely constructed object escaping into the wild. By providing the factory function create(), we make construction (on the free store) convenient.

Note#

Conventional factory functions allocate on the free store, rather than on the stack or in an enclosing object.

See also: (Discussion)

C.51: Use delegating constructors to represent common actions for all constructors of a class#

Reason#

To avoid repetition and accidental differences.

Example, bad#

class Date {   // BAD: repetitive
    int d;
    Month m;
    int y;
public:
    Date(int dd, Month mm, year yy)
        :d{dd}, m{mm}, y{yy}
        { if (!valid(d, m, y)) throw Bad_date{}; }
    Date(int dd, Month mm)
        :d{dd}, m{mm} y{current_year()}
        { if (!valid(d, m, y)) throw Bad_date{}; }
    // ...
};

The common action gets tedious to write and might accidentally not be common.

Example#

class Date2 {
    int d;
    Month m;
    int y;
public:
    Date2(int dd, Month mm, year yy)
        :d{dd}, m{mm}, y{yy}
        { if (!valid(d, m, y)) throw Bad_date{}; }
    Date2(int dd, Month mm)
        :Date2{dd, mm, current_year()} {}
    // ...
};

See also: If the "repeated action" is a simple initialization, consider (an in-class member initializer).

Enforcement#

(Moderate) Look for similar constructor bodies.

C.52: Use inheriting constructors to import constructors into a derived class that does not need further explicit initialization#

Reason#

If you need those constructors for a derived class, re-implementing them is tedious and error-prone.

Example#

std::vector has a lot of tricky constructors, so if I want my own vector, I don't want to reimplement them:

class Rec {
    // ... data and lots of nice constructors ...
};
class Oper : public Rec {
    using Rec::Rec;
    // ... no data members ...
    // ... lots of nice utility functions ...
};

Example, bad#

struct Rec2 : public Rec {
    int x;
    using Rec::Rec;
};
Rec2 r {"foo", 7};
int val = r.x;   // uninitialized

Enforcement#

Make sure that every member of the derived class is initialized.

C.copy: Copy and move#

Concrete types should generally be copyable, but interfaces in a class hierarchy should not. Resource handles might or might not be copyable. Types can be defined to move for logical as well as performance reasons.

C.60: Make copy assignment non-virtual, take the parameter by const&, and return by non-const&#

Reason#

It is simple and efficient. If you want to optimize for rvalues, provide an overload that takes a && (see (F.18)).

Example#

class Foo {
public:
    Foo& operator=(const Foo& x)
    {
        // GOOD: no need to check for self-assignment (other than performance)
        auto tmp = x;
        swap(tmp); // see C.83
        return *this;
    }
    // ...
};
Foo a;
Foo b;
Foo f();
a = b;    // assign lvalue: copy
a = f();  // assign rvalue: potentially move

Note#

The swap implementation technique offers the (strong guarantee).

Example#

But what if you can get significantly better performance by not making a temporary copy? Consider a simple Vector intended for a domain where assignment of large, equal-sized Vectors is common. In this case, the copy of elements implied by the swap implementation technique could cause an order of magnitude increase in cost:

template<typename T>
class Vector {
public:
    Vector& operator=(const Vector&);
    // ...
private:
    T* elem;
    int sz;
};
Vector& Vector::operator=(const Vector& a)
{
    if (a.sz > sz) {
        // ... use the swap technique, it can't be bettered ...
        return *this;
    }
    // ... copy sz elements from *a.elem to elem ...
    if (a.sz < sz) {
        // ... destroy the surplus elements in *this and adjust size ...
    }
    return *this;
}

By writing directly to the target elements, we will get only ((the basic guarantee) rather than the strong guarantee offered by the swap technique. Beware of self-assignment).

Alternatives: If you think you need a virtual assignment operator, and understand why that's deeply problematic, don't call it operator=. Make it a named function like virtual void assign(const Foo&). See (copy constructor vs. clone()).

Enforcement#

• (Simple) An assignment operator should not be virtual. Here be dragons!
• (Simple) An assignment operator should return T& to enable chaining, not alternatives like const T& which interfere with composability and putting objects in containers.
• (Moderate) An assignment operator should (implicitly or explicitly) invoke all base and member assignment operators. Look at the destructor to determine if the type has pointer semantics or value semantics.

C.61: A copy operation should copy#

Reason#

That is the generally assumed semantics. After x = y, we should have x == y. After a copy x and y can be independent objects (value semantics, the way non-pointer built-in types and the standard-library types work) or refer to a shared object (pointer semantics, the way pointers work).

Example#

class X {   // OK: value semantics
public:
    X();
    X(const X&);     // copy X
    void modify();   // change the value of X
    // ...
    ~X() { delete[] p; }
private:
    T* p;
    int sz;
};
bool operator==(const X& a, const X& b)
{
    return a.sz == b.sz && equal(a.p, a.p + a.sz, b.p, b.p + b.sz);
}
X::X(const X& a)
    :p{new T[a.sz]}, sz{a.sz}
{
    copy(a.p, a.p + sz, p);
}
X x;
X y = x;
if (x != y) throw Bad{};
x.modify();
if (x == y) throw Bad{};   // assume value semantics

Example#

class X2 {  // OK: pointer semantics
public:
    X2();
    X2(const X2&) = default; // shallow copy
    ~X2() = default;
    void modify();          // change the pointed-to value
    // ...
private:
    T* p;
    int sz;
};
bool operator==(const X2& a, const X2& b)
{
    return a.sz == b.sz && a.p == b.p;
}
X2 x;
X2 y = x;
if (x != y) throw Bad{};
x.modify();
if (x != y) throw Bad{};  // assume pointer semantics

Note#

Prefer value semantics unless you are building a "smart pointer". Value semantics is the simplest to reason about and what the standard-library facilities expect.

Enforcement#

(Not enforceable)

C.62: Make copy assignment safe for self-assignment#

Reason#

If x = x changes the value of x, people will be surprised and bad errors will occur (often including leaks).

Example#

The standard-library containers handle self-assignment elegantly and efficiently:

std::vector<int> v = {3, 1, 4, 1, 5, 9};
v = v;
// the value of v is still {3, 1, 4, 1, 5, 9}

Note#

The default assignment generated from members that handle self-assignment correctly handles self-assignment.

struct Bar {
    vector<pair<int, int>> v;
    map<string, int> m;
    string s;
};
Bar b;
// ...
b = b;   // correct and efficient

Note#

You can handle self-assignment by explicitly testing for self-assignment, but often it is faster and more elegant to cope without such a test (e.g., (using swap)).

class Foo {
    string s;
    int i;
public:
    Foo& operator=(const Foo& a);
    // ...
};
Foo& Foo::operator=(const Foo& a)   // OK, but there is a cost
{
    if (this == &a) return *this;
    s = a.s;
    i = a.i;
    return *this;
}