Moving to Modern C++

Chapter 1: Prefer nullptr

The literal 0 is an int. NULL is typically defined as 0 or 0L. Neither is a pointer. C++ grudgingly interprets them as null pointers when it has no other choice, but in overload resolution, they behave as integers:

c++
void f(int);
void f(bool);
void f(void*);

f(0);       // calls f(int), NOT f(void*)
f(NULL);    // might not compile, but never calls f(void*)
f(nullptr); // calls f(void*) as intended

nullptr has type std::nullptr_t, which implicitly converts to all raw pointer types but never to any integral type. This eliminates the entire class of ambiguity bugs.

c++
template<typename F, typename M, typename P>
auto lockAndCall(F func, M& mutex, P ptr) {
    std::lock_guard<M> g(mutex);
    return func(ptr);
}

lockAndCall(f1, f1m, 0);       // ERROR: int can't convert to shared_ptr
lockAndCall(f1, f1m, NULL);    // ERROR: same problem
lockAndCall(f1, f1m, nullptr); // OK: nullptr_t converts to shared_ptr

Chapter 2: Alias Declarations over typedefs

Both do the same job — create a shorter name for a type — but using has one killer advantage: it can be templatized.

c++
// typedef: no template support
typedef std::unique_ptr<std::unordered_map<std::string, std::string>> UPtrMapSS;

// alias declaration: same thing, but clearer
using UPtrMapSS = std::unique_ptr<std::unordered_map<std::string, std::string>>;

With function pointers, the alias is dramatically easier to read:

c++
// typedef: the name is buried in the middle
typedef void (*FP)(int, const std::string&);

// alias: name on the left, type on the right
using FP = void(*)(int, const std::string&);

The real power shows up with templates. A typedef can't be templatized directly — you have to wrap it in a struct. An alias template works cleanly:

c++
// Alias template: clean and simple
template<typename T>
using MyAllocList = std::list<T, MyAlloc<T>>;

MyAllocList<Widget> lw;  // clean usage

// typedef hack: requires struct wrapper + typename
template<typename T>
struct MyAllocList {
    typedef std::list<T, MyAlloc<T>> type;
};

MyAllocList<Widget>::type lw;  // clunky

Chapter 3: Scoped Enums

C++98 enums leak their enumerator names into the enclosing scope. C++11 enum class keeps them scoped:

c++
// C++98: names leak into surrounding scope
enum Color { black, white, red };
auto white = false;  // ERROR: white already declared

// C++11: names scoped to the enum
enum class Color { black, white, red };
auto white = false;           // fine, no conflict
Color c = Color::white;        // must qualify

Scoped enums also prevent implicit conversions to integers — no more accidentally passing a Color to a math function:

c++
// Unscoped: implicit conversion to int
enum Color { black, white, red };
if (black < 14.5) { ... }  // compiles! comparing Color to double

// Scoped: no implicit conversion
enum class Color { black, white, red };
if (Color::black < 14.5) { ... }  // ERROR: can't compare

Chapter 4: Deleted Functions

In C++98, the trick to prevent copying was to declare the copy constructor and copy assignment operator private and leave them undefined. It worked, but errors only surfaced at link time. C++11 gives us = delete:

c++98
// C++98: private and undefined
class NoCopy {
private:
    NoCopy(const NoCopy&);             // not defined
    NoCopy& operator=(const NoCopy&);  // not defined
};

c++11
// C++11: deleted — errors at compile time
class NoCopy {
public:
    NoCopy(const NoCopy&) = delete;
    NoCopy& operator=(const NoCopy&) = delete;
};

Two improvements: errors at compile time instead of link time, and they're public by convention so compilers give clear error messages about deletion rather than access violations.

c++
bool isLucky(int number);
bool isLucky(char) = delete;    // reject chars
bool isLucky(bool) = delete;    // reject bools
bool isLucky(double) = delete;  // reject doubles (and floats!)

isLucky(42);      // OK
isLucky('a');     // ERROR: deleted
isLucky(true);    // ERROR: deleted
isLucky(3.14);    // ERROR: deleted

Chapter 5: Declare Overrides override

Virtual function overriding is one of the most fundamental ideas in C++, and one of the easiest to get wrong silently. For overriding to happen, all of these must match between base and derived:

Can you spot the bugs? None of these derived functions override their base counterparts:

c++
class Base {
public:
    virtual void mf1() const;
    virtual void mf2(int x);
    virtual void mf3() &;
    void mf4() const;     // not virtual!
};

class Derived : public Base {
public:
    virtual void mf1();               // missing const
    virtual void mf2(unsigned int x); // wrong param type
    virtual void mf3() &&;           // wrong ref-qualifier
    void mf4() const;                // base isn't virtual
};

Add override and the compiler catches every one of these bugs:

c++11
class Derived : public Base {
public:
    void mf1() const override;           // OK
    void mf2(int x) override;           // OK
    void mf3() & override;              // OK
    // void mf4() const override;       // ERROR: base not virtual
};

Chapter 6: Prefer const_iterators

In C++98, const_iterators were impractical: hard to get from a non-const container, and insert/erase wouldn't accept them. C++11 fixes both problems:

c++98
// C++98: painful
typedef std::vector<int>::iterator iter;
typedef std::vector<int>::const_iterator cIter;
cIter ci = std::find(static_cast<cIter>(v.begin()),
                     static_cast<cIter>(v.end()), 1983);
v.insert(static_cast<iter>(ci), 1998);  // may not compile!

c++11
// C++11: trivial
auto it = std::find(v.cbegin(), v.cend(), 1983);
v.insert(it, 1998);  // just works

Chapter 7: noexcept

Declaring a function noexcept tells the compiler and callers that the function won't emit exceptions. This isn't just documentation — it enables optimizations:

c++
RetType function(params) noexcept;  // most optimizable
RetType function(params) throw();    // less optimizable (C++98)
RetType function(params);             // less optimizable

In a noexcept function, the optimizer doesn't have to keep the runtime stack in an unwindable state, and it doesn't have to guarantee objects are destroyed in reverse construction order if an exception escapes. This alone is reason enough to declare functions noexcept when they won't throw.

c++
// Without noexcept: vector copies elements on reallocation
Widget(Widget&& rhs);           // move ctor, might throw

// With noexcept: vector moves elements on reallocation (fast!)
Widget(Widget&& rhs) noexcept;  // move ctor, won't throw

Chapter 8: constexpr

constexpr means "this value is known at compile time" for objects, and "this function can be evaluated at compile time" for functions. It is not the same as const:

c++
int sz;                              // non-constexpr variable
constexpr auto arraySize1 = 10;     // fine: 10 is compile-time const
std::array<int, arraySize1> data1;  // fine: arraySize1 is constexpr

const auto arraySize2 = sz;          // fine: const copy of sz
std::array<int, arraySize2> data2;  // ERROR: arraySize2 not known at compile time

constexpr functions are dual-mode: call them with compile-time arguments and they compute at compile time; call with runtime values and they behave like normal functions:

c++
constexpr int pow(int base, int exp) noexcept {
    auto result = 1;
    for (int i = 0; i < exp; ++i) result *= base;
    return result;
}

constexpr auto numConds = 5;
std::array<int, pow(3, numConds)> results;  // 3^5 = 243 at compile time!

In C++11, constexpr functions are limited to a single return statement. C++14 lifts this restriction dramatically, allowing loops, local variables, and multiple statements.

Chapter 9: Thread-Safe const

A const member function promises not to modify the object. Multiple threads can call it simultaneously without synchronization — at least, that's the expectation. But if the function uses mutable data members for caching, that contract breaks:

c++
class Polynomial {
public:
    using RootsType = std::vector<double>;

    RootsType roots() const {
        if (!rootsAreValid) {       // read of mutable
            // ... compute roots ...
            rootsAreValid = true;   // write to mutable
        }
        return rootVals;
    }
private:
    mutable bool rootsAreValid{ false };
    mutable RootsType rootVals{};
};

If two threads call roots() simultaneously, they race on rootsAreValid and rootVals. This is undefined behavior even though roots() is const.

c++
class Polynomial {
public:
    RootsType roots() const {
        std::lock_guard<std::mutex> g(m);  // lock
        if (!rootsAreValid) {
            // ... compute roots ...
            rootsAreValid = true;
        }
        return rootVals;
    }                                       // unlock
private:
    mutable std::mutex m;
    mutable bool rootsAreValid{ false };
    mutable RootsType rootVals{};
};

Chapter 10: Special Member Function Generation

C++98 had four special member functions the compiler could generate: default constructor, destructor, copy constructor, and copy assignment operator. C++11 adds two more: the move constructor and move assignment operator.

But the generation rules are subtle. The two copy operations are independent: declaring one doesn't suppress the other. The two move operations are not independent: declaring either suppresses the other.

Move operations are generated only when all three conditions are true:

c++11
class Widget {
public:
    ~Widget();                                  // custom dtor
    Widget(const Widget&) = default;           // force generation
    Widget& operator=(const Widget&) = default;  // force generation
    Widget(Widget&&) = default;                // force generation
    Widget& operator=(Widget&&) = default;       // force generation
};