Modern C++ Programming Cookbook: Recipes to explore data structure, multithreading, and networking in C++17

Consider using auto as a placeholder for the actual type in the following situations:

        auto i = 42;          // int 
        auto d = 42.5;        // double 
        auto s = "text";      // char const * 
        auto v = { 1, 2, 3 }; // std::initializer_list<int> 

        auto b  = new char[10]{ 0 };            // char* 
        auto s1 = std::string {"text"};         // std::string
        auto v1 = std::vector<int> { 1, 2, 3 }; // std::vector<int>
        auto p  = std::make_shared<int>(42);    // std::shared_ptr<int>

        auto upper = [](char const c) {return toupper(c); };

        auto add = [](auto const a, auto const b) {return a + b;};

        template <typename F, typename T> 
        auto apply(F&& f, T value) 
        { 
          return f(value); 
        }

The auto specifier is basically a placeholder for an actual type. When using auto, the compiler deduces the actual type from the following instances:

In some cases, it is necessary to commit to a specific type. For instance, in the preceding example, the compiler deduces the type of s to be char const *. If the intention was to have a std::string, then the type must be specified explicitly. Similarly, the type of v was deduced as std::initializer_list<int>. However, the intention could be to have a std::vector<int>. In such cases, the type must be specified explicitly on the right side of the assignment.

There are some important benefits of using the auto specifier instead of actual types; the following is a list of, perhaps, the most important ones:

        auto v = std::vector<int>{ 1, 2, 3 }; 
        int size1 = v.size();       
        // implicit conversion, possible loss of data 
        auto size2 = v.size(); 
        auto size3 = int{ v.size() };  // error, narrowing conversion

        std::map<int, std::string> m; 
        for (std::map<int,std::string>::const_iterator it = m.cbegin();
          it != m.cend(); ++it) 
        { /*...*/ } 

        for (auto it = m.cbegin(); it != m.cend(); ++it)
        { /*...*/ }

However, there are some gotchas when using auto:

        class foo { 
          int x_; 
        public: 
          foo(int const x = 0) :x_{ x } {} 
          int& get() { return x_; } 
        }; 

        foo f(42); 
        auto x = f.get(); 
        x = 100; 
        std::cout << f.get() << std::endl; // prints 42

        auto ai = std::atomic<int>(42); // error

        auto l1 = long long{ 42 }; // error 
        auto l2 = llong{ 42 };     // OK 
        auto l3 = 42LL;            // OK

The auto can be used to specify the return type from a function. In C++11, this requires a trailing return type in the function declaration. In C++14, this has been relaxed, and the type of the return value is deduced by the compiler from the return expression. If there are multiple return values they should have the same type:

    // C++11 
    auto func1(int const i) -> int 
    { return 2*i; } 

    // C++14 
    auto func2(int const i) 
    { return 2*i; }

As mentioned earlier, auto does not retain const/volatile and reference qualifiers. This leads to problems with auto as a placeholder for the return type from a function. To explain this, let us consider the preceding example with foo.get(). This time we have a wrapper function called proxy_get() that takes a reference to a foo, calls get(), and returns the value returned by get(), which is an int&. However, the compiler will deduce the return type of proxy_get() as being int, not int&. Trying to assign that value to an int& fails with an error:

    class foo 
    { 
      int x_; 
    public: 
      foo(int const x = 0) :x_{ x } {} 
      int& get() { return x_; } 
    }; 

    auto proxy_get(foo& f) { return f.get(); } 

    auto f = foo{ 42 }; 
    auto& x = proxy_get(f); // cannot convert from 'int' to 'int &'

To fix this, we need to actually return auto&. However, this is a problem with templates and perfect forwarding the return type without knowing whether that is a value or a reference. The solution to this problem in C++14 is decltype(auto) that will correctly deduce the type:

    decltype(auto) proxy_get(foo& f) { return f.get(); } 
    auto f = foo{ 42 }; 
    decltype(auto) x = proxy_get(f);

The last important case where auto can be used is with lambdas. As of C++14, both lambda return type and lambda parameter types can be auto. Such a lambda is called a generic lambda because the closure type defined by the lambda has a templated call operator. The following shows a generic lambda that takes two auto parameters and returns the result of applying operator+ on the actual types:

    auto ladd = [] (auto const a, auto const b) { return a + b; }; 
    struct 
    { 
       template<typename T, typename U> 
       auto operator () (T const a, U const b) const { return a+b; } 
    } L;

This lambda can be used to add anything for which the operator+ is defined. In the following example, we use the lambda to add two integers and to concatenate to std::string objects (using the C++14 user-defined literal operator ""s):

    auto i = ladd(40, 2);            // 42 
    auto s = ladd("forty"s, "two"s); // "fortytwo"s

        using byte    = unsigned char; 
        using pbyte   = unsigned char *; 
        using array_t = int[10]; 
        using fn      = void(byte, double); 

        void func(byte b, double d) { /*...*/ } 

        byte b {42}; 
        pbyte pb = new byte[10] {0}; 
        array_t a{0,1,2,3,4,5,6,7,8,9}; 
        fn* f = func;

        template <class T> 
        class custom_allocator { /* ... */}; 

        template <typename T> 
        using vec_t = std::vector<T, custom_allocator<T>>; 

        vec_t<int>           vi; 
        vec_t<std::string>   vs; 

For consistency and readability, you should do the following:

A typedef declaration introduces a synonym (or an alias in other words) for a type. It does not introduce another type (like a class, struct, union, or enum declaration). Type names introduced with a typedef declaration follow the same hiding rules as identifier names. They can also be redeclared, but only to refer to the same type (therefore, you can have valid multiple typedef declarations that introduce the same type name synonym in a translation unit as long as it is a synonym for the same type). The following are typical examples of typedef declarations:

    typedef unsigned char   byte; 
    typedef unsigned char * pbyte; 
    typedef int             array_t[10]; 
    typedef void(*fn)(byte, double); 

    template<typename T> 
    class foo { 
      typedef T value_type; 
    }; 

    typedef std::vector<int> vint_t;

A type alias declaration is equivalent to a typedef declaration. It can appear in a block scope, class scope, or namespace scope. According to C++11 paragraph 7.1.3.2:

An alias-declaration is, however, more readable and more clear about the actual type that is aliased when it comes to creating aliases for array types and function pointer types. In the examples from the How to do it... section, it is easily understandable that array_t is a name for the type array of 10 integers, and fn is a name for a function type that takes two parameters of type byte and double and returns void. That is also consistent with the syntax for declaring std::function objects (for example, std::function<void(byte, double)> f).

The driving purpose of the new syntax is to define alias templates. These are templates which, when specialized, are equivalent to the result of substituting the template arguments of the alias template for the template parameters in the type-id.

It is important to take note of the following things:

For continuing with this recipe, you need to be familiar with direct initialization that initializes an object from an explicit set of constructor arguments and copy initialization that initializes an object from another object. The following is a simple example of both types of initialization, but for further details, you should see additional resources:

    std::string s1("test");   // direct initialization 
    std::string s2 = "test";  // copy initialization

To uniformly initialize objects regardless of their type, use the brace-initialization form {} that can be used for both direct initialization and copy initialization. When used with brace initialization, these are called direct list and copy list initialization.

    T object {other};   // direct list initialization 
    T object = {other}; // copy list initialization

Examples of uniform initialization are as follows:

        std::vector<int> v { 1, 2, 3 };
        std::map<int, std::string> m { {1, "one"}, { 2, "two" }};

        int* arr2 = new int[3]{ 1, 2, 3 };    

        int arr1[3] { 1, 2, 3 }; 

        int i { 42 };
        double d { 1.2 };    

        class foo
        {
          int a_;
          double b_;
        public:
          foo():a_(0), b_(0) {}
          foo(int a, double b = 0.0):a_(a), b_(b) {}
        };

        foo f1{}; 
        foo f2{ 42, 1.2 }; 
        foo f3{ 42 };

        struct bar { int a_; double b_;};
        bar b{ 42, 1.2 };

Before C++11 objects required different types of initialization based on their type:

        int a = 42; 
        double b = 1.2;

        class foo 
        { 
          int a_; 
        public: 
          foo(int a):a_(a) {} 
        }; 
        foo f1 = 42;

        foo f1;           // default initialization 
        foo f2(42, 1.2); 
        foo f3(42); 
        foo f4();         // function declaration

        bar b = {42, 1.2}; 
        int a[] = {1, 2, 3, 4, 5};

Apart from the different methods of initializing the data, there are also some limitations. For instance, the only way to initialize a standard container was to first declare an object and then insert elements into it; vector was an exception because it is possible to assign values from an array that can be prior initialized using aggregate initialization. On the other hand, however, dynamically allocated aggregates could not be initialized directly.

All the examples in the How to do it... section use direct initialization, but copy initialization is also possible with brace-initialization. The two forms, direct and copy initialization, may be equivalent in most cases, but copy initialization is less permissive because it does not consider explicit constructors in its implicit conversion sequence that must produce an object directly from the initializer, whereas direct initialization expects an implicit conversion from the initializer to an argument of the constructor. Dynamically allocated arrays can only be initialized using direct initialization.

Of the classes shown in the preceding examples, foo is the one class that has both a default constructor and a constructor with parameters. To use the default constructor to perform default initialization, we need to use empty braces, that is, {}. To use the constructor with parameters, we need to provide the values for all the arguments in braces {}. Unlike non-aggregate types where default initialization means invoking the default constructor, for aggregate types, default initialization means initializing with zeros.

Initialization of standard containers, such as the vector and the map also shown above, is possible because all standard containers have an additional constructor in C++11 that takes an argument of type std::initializer_list<T>. This is basically a lightweight proxy over an array of elements of type T const. These constructors then initialize the internal data from the values in the initializer list.

The way the initialization using std::initializer_list works is the following:

An initializer list always takes precedence over other constructors where brace-initialization is used. If such a constructor exists for a class, it will be called when brace-initialization is performed:

    class foo 
    { 
      int a_; 
      int b_; 
    public: 
      foo() :a_(0), b_(0) {} 

      foo(int a, int b = 0) :a_(a), b_(b) {} 
      foo(std::initializer_list<int> l) {} 
    }; 

    foo f{ 1, 2 }; // calls constructor with initializer_list<int>

The precedence rule applies to any function, not just constructors. In the following example, two overloads of the same function exist. Calling the function with an initializer list resolves to a call to the overload with an std::initializer_list:

    void func(int const a, int const b, int const c) 
    { 
      std::cout << a << b << c << std::endl; 
    } 

    void func(std::initializer_list<int> const l) 
    { 
      for (auto const & e : l) 
        std::cout << e << std::endl; 
    } 

    func({ 1,2,3 }); // calls second overload

This, however, has the potential of leading to bugs. Let's take, for example, the vector type. Among the constructors of the vector, there is one that has a single argument representing the initial number of elements to be allocated and another one that has an std::initializer_list as an argument. If the intention is to create a vector with a preallocated size, using the brace-initialization will not work, as the constructor with the std::initializer_list will be the best overload to be called:

    std::vector<int> v {5};

The preceding code does not create a vector with five elements, but a vector with one element with a value 5. To be able to actually create a vector with five elements, initialization with the parentheses form must be used:

    std::vector<int> v (5);

Another thing to note is that brace-initialization does not allow narrowing conversion. According to the C++ standard (refer to paragraph 8.5.4 of the standard), a narrowing conversion is an implicit conversion:

The following declarations trigger compiler errors because they require a narrowing conversion:

    int i{ 1.2 };           // error 

    double d = 47 / 13; 
    float f1{ d };          // error 
    float f2{47/13};        // OK

To fix the error, an explicit conversion must be done:

    int i{ static_cast<int>(1.2) }; 

    double d = 47 / 13; 
    float f1{ static_cast<float>(d) };

The following sample shows several examples of direct-list-initialization and copy-list-initialization. In C++11, the deduced type of all these expressions is std::initializer_list<int>.

auto a = {42};   // std::initializer_list<int>
auto b {42};     // std::initializer_list<int>
auto c = {4, 2}; // std::initializer_list<int>
auto d {4, 2};   // std::initializer_list<int>

C++17 has changed the rules for list initialization, differentiating between the direct- and copy-list-initialization. The new rules for type deduction are as follows:

Base on the new rules, the previous examples would change as follows: a and c are deduced as std::initializer_list<int>; b is deduced as an int; d, which uses direct initialization and has more than one value in the brace-init-list, triggers a compiler error.

auto a = {42};   // std::initializer_list<int>
auto b {42};     // int
auto c = {4, 2}; // std::initializer_list<int>
auto d {4, 2};   // error, too many

To initialize non-static members of a class you should:

The following example shows these forms of initialization:

    struct Control 
    { 
      const int DefaultHeigh = 14;                  // [1]
      const int DefaultWidth = 80;                  // [2]

      TextVAligment valign = TextVAligment::Middle; // [3]
      TextHAligment halign = TextHAligment::Left;   // [4]

      std::string text; 

      Control(std::string const & t) : text(t)       // [5]
      {} 

      Control(std::string const & t, 
        TextVerticalAligment const va, 
        TextHorizontalAligment const ha):  
      text(t), valign(va), halign(ha)                 // [6]
      {} 
    };

Non-static data members are supposed to be initialized in the constructor's initializer list as shown in the following example:

    struct Point 
    { 
      double X, Y; 
      Point(double const x = 0.0, double const y = 0.0) : X(x), Y(y)  {} 
    };

Many developers, however, do not use the initializer list, but prefer assignments in the constructor's body, or even mix assignments and the initializer list. That could be for several reasons--for larger classes with many members, the constructor assignments may look easier to read than long initializer lists, perhaps split on many lines, or it could be because they are familiar with other programming languages that don't have an initializer list or because, unfortunately, for various reasons they don't even know about it.

Using assignments in the constructor is not efficient, as this can create temporary objects that are later discarded. If not initialized in the initializer list, non-static members are initialized via their default constructor and then, when assigned a value in the constructor's body, the assignment operator is invoked. This can lead to inefficient work if the default constructor allocates a resource (such as memory or a file) and that has to be deallocated and reallocated in the assignment operator:

    struct foo 
    { 
      foo()  
      { std::cout << "default constructor" << std::endl; } 
      foo(std::string const & text)  
      { std::cout << "constructor '" << text << "'" << std::endl; } 
      foo(foo const & other)
      { std::cout << "copy constructor" << std::endl; } 
      foo(foo&& other)  
      { std::cout << "move constructor" << std::endl; }; 
      foo& operator=(foo const & other)  
      { std::cout << "assignment" << std::endl; return *this; } 
      foo& operator=(foo&& other)  
      { std::cout << "move assignment" << std::endl; return *this;} 
      ~foo()  
      { std::cout << "destructor" << std::endl; } 
    }; 

    struct bar 
    { 
      foo f; 

      bar(foo const & value) 
      { 
        f = value; 
      } 
    }; 

    foo f; 
    bar b(f);

The preceding code produces the following output showing how data member f is first default initialized and then assigned a new value:

default constructor 
default constructor 
assignment 
destructor 
destructor

Changing the initialization from the assignment in the constructor body to the initializer list replaces the calls to the default constructor plus assignment operator with a call to the copy constructor:

    bar(foo const & value) : f(value) { }

Adding the preceding line of code produces the following output:

default constructor 
copy constructor 
destructor 
destructor

For those reasons, at least for other types than the built-in types (such as bool, char, int, float, double or pointers), you should prefer the constructor initializer list. However, to be consistent with your initialization style, you should always prefer the constructor initializer list when that is possible. There are several situations when using the initializer list is not possible; these include the following cases (but the list could be expanded with other cases):

Starting with C++11, non-static data members can be initialized when declared in the class. This is called default member initialization because it is supposed to represent initialization with default values. Default member initialization is intended for constants and for members that are not initialized based on constructor parameters (in other words members whose value does not depend on the way the object is constructed):

    enum class TextFlow { LeftToRight, RightToLeft }; 

    struct Control 
    { 
      const int DefaultHeight = 20; 
      const int DefaultWidth = 100; 

      TextFlow textFlow = TextFlow::LeftToRight; 
      std::string text; 

      Control(std::string t) : text(t) 
      {} 
    };

In the preceding example, DefaultHeight and DefaultWidth are both constants; therefore, the values do not depend on the way the object is constructed, so they are initialized when declared. The textFlow object is a non-constant non-static data member whose value also does not depend on the way the object is initialized (it could be changed via another member function), therefore, it is also initialized using default member initialization when it is declared. text, on the other hand, is also a non-constant non-static data member, but its initial value depends on the way the object is constructed and therefore it is initialized in the constructor's initializer list using a value passed as an argument to the constructor.

If a data member is initialized both with the default member initialization and constructor initializer list, the latter takes precedence and the default value is discarded. To exemplify this, let's again consider the foo class earlier and the following bar class that uses it:

    struct bar 
    { 
      foo f{"default value"}; 

      bar() : f{"constructor initializer"} 
      { 
      } 
    }; 

    bar b;

The output differs, in this case, as follows, because the value from the default initializer list is discarded, and the object is not initialized twice:

constructor
constructor initializer
destructor

You should be familiar with what data alignment is and the way the compiler performs default data alignment. However, basic information about the latter is provided in the How it works... section.

        struct alignas(4) foo 
        { 
          char a; 
          char b; 
        }; 
        struct bar 
        { 
          alignas(2) char a; 
          alignas(8) int  b; 
        }; 
        alignas(8)   int a; 
        alignas(256) long b[4];

        auto align = alignof(foo);

Processors do not access memory one byte at a time, but in larger chunks of powers of twos (2, 4, 8, 16, 32, and so on). Owing to this, it is important that compilers align data in memory so that it can be easily accessed by the processor. Should this data be misaligned, the compiler has to do extra work for accessing data; it has to read multiple chunks of data, shift, and discard unnecessary bytes and combine the rest together.

C++ compilers align variables based on the size of their data type: 1 byte for bool and char, 2 bytes for short, 4 bytes for int, long and float, 8 bytes for double and long long, and so on. When it comes to structures or unions, the alignment must match the size of the largest member in order to avoid performance issues. To exemplify, let's consider the following data structures:

    struct foo1    // size = 1, alignment = 1 
    { 
      char a; 
    }; 

    struct foo2    // size = 2, alignment = 1 
    { 
      char a; 
      char b; 
    }; 

    struct foo3    // size = 8, alignment = 4 
    { 
      char a; 
      int  b; 
    };

foo1 and foo2 have different sizes, but the alignment is the same--that is, 1--because all data members are of type char, which has a size of 1. In structure foo3, the second member is an integer, whose size is 4. As a result, the alignment of members of this structure is done at addresses that are multiples of 4. To achieve that, the compiler introduces padding bytes. The structure foo3 is actually transformed into the following:

    struct foo3_ 
    { 
      char a;        // 1 byte 
      char _pad0[3]; // 3 bytes padding to put b on a 4-byte boundary 
      int  b;        // 4 bytes 
    };

Similarly, the following structure has a size of 32 bytes and an alignment of 8; that is because the largest member is a double whose size is 8. This structure, however, requires padding in several places to make sure that all members can be accessed at addresses that are multiples of 8:

    struct foo4 
    { 
      int a; 
      char b; 
      float c; 
      double d; 
      bool e; 
    };

The equivalent structure created by the compiler is as follows:

    struct foo4_ 
    { 
      int a;         // 4 bytes 
      char b;        // 1 byte 
      char _pad0[3]; // 3 bytes padding to put c on a 8-byte boundary  
      float c;       // 4 bytes 
      char _pad1[4]; // 4 bytes padding to put d on a 8-byte boundary 
      double d;      // 8 bytes 
      bool e;        // 1 byte 
      char _pad2[7]; // 7 bytes padding to make sizeof struct multiple of 8 
    };

In C++11, specifying the alignment of an object or type is done using the alignas specifier. This can take either an expression (an integral constant expression that evaluates to 0 or a valid value for an alignment), a type-id, or a parameter pack. The alignas specifier can be applied to the declaration of a variable or a class data member that does not represent a bit field, or to the declaration of a class, union, or enumeration. The type or object on which an alignas specification is applied will have the alignment requirement equal to the largest, greater than zero, expression of all alignas specifications used in the declaration.

There are several restrictions when using the alignas specifier:

In the following example, the alignas specifier is applied on a class declaration. The natural alignment without the alignas specifier would have been 1, but with alignas(4) it becomes 4:

    struct alignas(4) foo 
    { 
      char a; 
      char b; 
    };

In other words, the compiler transforms the preceding class into the following:

    struct foo 
    { 
      char a; 
      char b; 
      char _pad0[2]; 
    };

The alignas specifier can be applied both on the class declaration and the member data declarations. In this case, the strictest (that is, largest) value wins. In the following example, member a has a natural size of 1 and requires an alignment of 2; member b has a natural size of 4 and requires an alignment of 8, therefore, the strictest alignment would be 8. The alignment requirement of the entire class is 4, which is weaker (that is, smaller) than the strictest required alignment and therefore it will be ignored, though the compiler will produce a warning:

    struct alignas(4) foo 
    { 
      alignas(2) char a; 
      alignas(8) int  b; 
    };

The result is a structure that looks like this:

    struct foo 
    { 
      char a; 
      char _pad0[7]; 
      int b; 
      char _pad1[4]; 
    };

The alignas specifier can also be applied on variables. In the next example, variable a, that is an integer, is required to be placed in memory at a multiple of 8. The next variable, the array of 4 a, that is an integer, is required to be placed in memory at a multiple of 8. The next variable, the array of 4 longs, is required to be placed in memory at a multiple of 256. As a result, the compiler will introduce up to 244 bytes of padding between the two variables (depending on where in memory, at an address multiple of 8, the variable a is located):

    alignas(8)   int a;   
    alignas(256) long b[4]; 

    printf("%pn", &a); // eg. 0000006C0D9EF908 
    printf("%pn", &b); // eg. 0000006C0D9EFA00

Looking at the addresses, we can see that the address of a is indeed a multiple of 8, and the address of b is a multiple of 256 (hexadecimal 100).

To query the alignment of a type, we use the alignof operator. Unlike sizeof, this operator can only be applied to type-ids, and not on variables or class data members. The types on which it can be applied can be complete types, an array type, or a reference type. For arrays, the value returned is the alignment of the element type; for references, the value returned is the alignment of the referenced type. Here are several examples:

        enum class Status { Unknown, Created, Connected };
        Status s = Status::Created;

Unscoped enumerations have several issues that are creating problems for developers:

        enum Status {Unknown, Created, Connected};
        enum Codes {OK, Failure, Unknown};   // error 
        auto status = Status::Created;       // error

        enum Codes { OK, Failure }; 
        void include_offset(int pixels) {/*...*/} 
        include_offset(Failure);

The scoped enumerations are basically strongly typed enumerations that behave differently than the unscoped enumerations:

        enum class Status { Unknown, Created, Connected }; 
        enum class Codes { OK, Failure, Unknown }; // OK 
        Codes code = Codes::Unknown;               // OK

        enum class Codes : unsigned int; 

        void print_code(Codes const code) {} 

        enum class Codes : unsigned int 
        {  
           OK = 0,  
           Failure = 1,  
           Unknown = 0xFFFF0000U 
        };

        Codes c1 = Codes::OK;                       // OK 
        int c2 = Codes::Failure;                    // error 
        int c3 = static_cast<int>(Codes::Failure);  // OK

You should be familiar with inheritance and polymorphism in C++ and concepts, such as abstract classes, pure specifiers, virtual, and overridden methods.

To ensure correct declaration of virtual methods both in base and derived classes, but also increase readability, do the following:

        class Base 
        { 
          virtual void foo() = 0;
          virtual void bar() {} 
          virtual void foobar() = 0; 
        };

        void Base::foobar() {}

        class Derived1 : public Base 
        { 
          virtual void foo() override = 0;
          virtual void bar() override {}
          virtual void foobar() override {} 
        }; 

        class Derived2 : public Derived1 
        { 
          virtual void foo() override {} 
        };

To ensure that functions cannot be overridden further or classes cannot be derived any more, use the final special identifier:

        class Derived2 : public Derived1 
        { 
          virtual void foo() final {} 
        };

        class Derived4 final : public Derived1 
        { 
          virtual void foo() override {} 
        };

The way override works is very simple; in a virtual function declaration or definition, it ensures that the function is actually overriding a base class function, otherwise, the compiler will trigger an error.

It should be noted that both override and final keywords are special identifiers having a meaning only in a member function declaration or definition. They are not reserved keywords and can still be used elsewhere in a program as user-defined identifiers.

Using the override special identifier helps the compiler to detect situations when a virtual method does not override another one like shown in the following example:

    class Base 
    { 
    public: 
      virtual void foo() {}
      virtual void bar() {}
    }; 

    class Derived1 : public Base 
    { 
    public:    
      void foo() override {}
      // for readability use the virtual keyword    

      virtual void bar(char const c) override {}
      // error, no Base::bar(char const) 
    };

The other special identifier, final, is used in a member function declaration or definition to indicate that the function is virtual and cannot be overridden in a derived class. If a derived class attempts to override the virtual function, the compiler triggers an error:

    class Derived2 : public Derived1 
    { 
      virtual void foo() final {} 
    }; 

    class Derived3 : public Derived2 
    { 
      virtual void foo() override {} // error 
    };

The final specifier can also be used in a class declaration to indicate that it cannot be derived:

    class Derived4 final : public Derived1 
    { 
      virtual void foo() override {} 
    };

    class Derived5 : public Derived4 // error 
    { 
    };

Since both override and final have this special meaning when used in the defined context and are not in fact reserved keywords, you can still use them anywhere elsewhere in the C++ code. This ensured that existing code written before C++11 did not break because of the use of these names for identifiers:

    class foo 
    { 
      int final = 0; 
      void override() {} 
    };

In C++11, a range-based for loop has the following general syntax:

    for ( range_declaration : range_expression ) loop_statement

To exemplify the various ways of using a range-based for loops, we will use the following functions that return sequences of elements:

    std::vector<int> getRates() 
    { 
      return std::vector<int> {1, 1, 2, 3, 5, 8, 13}; 
    } 

    std::multimap<int, bool> getRates2() 
    { 
      return std::multimap<int, bool> { 
        { 1, true }, 
        { 1, true }, 
        { 2, false }, 
        { 3, true }, 
        { 5, true }, 
        { 8, false }, 
        { 13, true } 
      }; 
    }

Range-based for loops can be used in various ways:

        auto rates = getRates();
        for (int rate : rates) 
          std::cout << rate << std::endl; 
        for (int& rate : rates) 
          rate *= 2;

        for (auto&& rate : getRates()) 
          std::cout << rate << std::endl; 

        for (auto & rate : rates) 
          rate *= 2; 

        for (auto const & rate : rates) 
          std::cout << rate << std::endl;

        for (auto&& [rate, flag] : getRates2()) 
          std::cout << rate << std::endl;

The expression for the range-based for loops shown earlier in the How to do it... section is basically syntactic sugar as the compiler transforms it into something else. Before C++17, the code generated by the compiler used to be the following:

    { 
      auto && __range = range_expression; 
      for (auto __begin = begin_expr, __end = end_expr; 
      __begin != __end; ++__begin) { 
        range_declaration = *__begin; 
        loop_statement 
      } 
    }

What begin_expr and end_expr are in this code depends on the type of the range:

It is important to note that if a class contains any members (function, data member, or enumerators) called begin or end, regardless of their type and accessibility, they will be picked for begin_expr and end_expr. Therefore, such a class type cannot be used in range-based for loops.

In C++17, the code generated by the compiler is slightly different:

    { 
      auto && __range = range_expression; 
      auto __begin = begin_expr; 
      auto __end = end_expr; 
      for (; __begin != __end; ++__begin) { 
        range_declaration = *__begin; 
        loop_statement 
      } 
    }

The new standard has removed the constraint that the begin expression and end expression must have the same type. The end expression does not need to be an actual iterator, but it has to be able to be compared for inequality with an iterator. A benefit of this is that the range can be delimited by a predicate.

It is recommended that you read the recipe Using range-based for loops to iterate on a range before continuing with this one if you need to understand how range-based for loops work and what is the code the compiler generates for such a loop.

To show how we can enable range-based for loops for custom types representing sequences, we will use the following implementation of a simple array:

    template <typename T, size_t const Size> 
    class dummy_array 
    { 
      T data[Size] = {}; 

    public: 
      T const & GetAt(size_t const index) const 
      { 
        if (index < Size) return data[index]; 
        throw std::out_of_range("index out of range"); 
      } 

      void SetAt(size_t const index, T const & value) 
      { 
        if (index < Size) data[index] = value; 
        else throw std::out_of_range("index out of range"); 
      } 

      size_t GetSize() const { return Size; } 
    };

The purpose of this recipe is to enable writing code like the following:

    dummy_array<int, 3> arr; 
    arr.SetAt(0, 1); 
    arr.SetAt(1, 2); 
    arr.SetAt(2, 3); 

    for(auto&& e : arr) 
    {  
      std::cout << e << std::endl; 
    }

To enable a custom type to be used in range-based for loops, you need to do the following:

Given the earlier example of a simple range, we need to provide the following:

        template <typename T, typename C, size_t const Size> 
        class dummy_array_iterator_type 
        { 
        public: 
          dummy_array_iterator_type(C& collection,  
                                    size_t const index) : 
          index(index), collection(collection) 
          { } 

        bool operator!= (dummy_array_iterator_type const & other) const 
        { 
          return index != other.index; 
        } 

        T const & operator* () const 
        { 
          return collection.GetAt(index); 
        } 

        dummy_array_iterator_type const & operator++ () 
        { 
          ++index; 
          return *this; 
        } 

        private: 
          size_t   index; 
          C&       collection; 
        };

        template <typename T, size_t const Size> 
        using dummy_array_iterator =  
           dummy_array_iterator_type< 
             T, dummy_array<T, Size>, Size>; 

        template <typename T, size_t const Size> 
        using dummy_array_const_iterator =  
           dummy_array_iterator_type< 
             T, dummy_array<T, Size> const, Size>;

        template <typename T, size_t const Size> 
        inline dummy_array_iterator<T, Size> begin(
          dummy_array<T, Size>& collection) 
        { 
          return dummy_array_iterator<T, Size>(collection, 0); 
        } 

        template <typename T, size_t const Size> 
        inline dummy_array_iterator<T, Size> end(
          dummy_array<T, Size>& collection) 
        { 
          return dummy_array_iterator<T, Size>(
            collection, collection.GetSize()); 
        } 

        template <typename T, size_t const Size> 
        inline dummy_array_const_iterator<T, Size> begin( 
          dummy_array<T, Size> const & collection) 
        { 
          return dummy_array_const_iterator<T, Size>( 
            collection, 0); 
        } 

        template <typename T, size_t const Size> 
        inline dummy_array_const_iterator<T, Size> end( 
          dummy_array<T, Size> const & collection) 
        { 
          return dummy_array_const_iterator<T, Size>( 
            collection, collection.GetSize()); 
        }

Having this implementation available, the range-based for loop shown earlier compiles and executes as expected. When performing argument dependent lookup, the compiler will identify the two begin() and end() functions that we wrote (that take a reference to a dummy_array) and therefore the code it generates becomes valid.

In the preceding example, we have defined one iterator class template and two alias templates, called dummy_array_iterator and dummy_array_const_iterator. The begin() and end() functions both have two overloads for these two types of iterators. This is necessary so that the container we have considered could be used in range-based for loops with both constant and non-constant instances:

    template <typename T, const size_t Size> 
    void print_dummy_array(dummy_array<T, Size> const & arr) 
    { 
      for (auto && e : arr) 
      { 
        std::cout << e << std::endl; 
      } 
    }

A possible alternative to enable range-based for loops for the simple range class we considered for this recipe is to provide member begin() and end() functions. In general, that could make sense only if you own and can modify the source code. On the other hand, the solution shown in this recipe works in all cases and should be preferred to other alternatives.

For this recipe, you need to be familiar with converting constructors and converting operators. In this recipe, you will learn how to write explicit constructors and conversion operators to avoid implicit conversions to and from a type. The use of explicit constructors and conversion operators (called user-defined conversion functions) enables the compiler to yield errors--that in some cases are coding errors--and allow developers to spot those errors quickly and fix them.

To declare explicit constructors and conversion operators (regardless of whether they are functions or function templates), use the explicit specifier in the declaration.

The following example shows both an explicit constructor and a converting operator:

    struct handle_t 
    { 
      explicit handle_t(int const h) : handle(h) {} 

      explicit operator bool() const { return handle != 0; }; 
    private: 
      int handle; 
    };

To understand why explicit constructors are necessary and how they work, we will first look at converting constructors. The following class has three constructors: a default constructor (without parameters), a constructor that takes an int, and a constructor that takes two parameters, an int and a double. They don't do anything, except printing a message. As of C++11, these are all considered converting constructors. The class also has a conversion operator that converts the type to a bool:

    struct foo 
    { 
      foo()
      { std::cout << "foo" << std::endl; }
      foo(int const a)
      { std::cout << "foo(a)" << std::endl; }
      foo(int const a, double const b)
      { std::cout << "foo(a, b)" << std::endl; } 

      operator bool() const { return true; } 
    };

Based on this, the following definitions of objects are possible (note that the comments represent the console output):

    foo f1;              // foo
    foo f2 {};           // foo

    foo f3(1);           // foo(a)
    foo f4 = 1;          // foo(a)
    foo f5 { 1 };        // foo(a)
    foo f6 = { 1 };      // foo(a)

    foo f7(1, 2.0);      // foo(a, b)
    foo f8 { 1, 2.0 };   // foo(a, b)
    foo f9 = { 1, 2.0 }; // foo(a, b)

f1 and f2 invoke the default constructor. f3, f4, f5, and f6 invoke the constructor that takes an int. Note that all the definitions of these objects are equivalent, even if they look different (f3 is initialized using the functional form, f4 and f6 are copy initialized, and f5 is directly initialized using brace-init-list). Similarly, f7, f8, and f9 invoke the constructor with two parameters.

It may be important to note that if foo defines a constructor that takes an std::initializer_list, then all the initializations using {} would resolve to that constructor:

    foo(std::initializer_list<int> l)  
    { std::cout << "foo(l)" << std::endl; }

In this case, f5 and f6 will print foo(l), while f8 and f9 will generate compiler errors because all elements of the initializer list should be integers.

These may all look right, but the implicit conversion constructors enable scenarios where the implicit conversion may not be what we wanted:

    void bar(foo const f) 
    { 
    } 

    bar({});             // foo()
    bar(1);              // foo(a)
    bar({ 1, 2.0 });     // foo(a, b)

The conversion operator to bool in the example above also enables us to use foo objects where boolean values are expected:

    bool flag = f1; 
    if(f2) {} 
    std::cout << f3 + f4 << std::endl; 
    if(f5 == f6) {}

The first two are examples where foo is expected to be used as boolean but the last two with addition and test for equality are probably incorrect, as we most likely expect to add foo objects and test foo objects for equality, not the booleans they implicitly convert to.

Perhaps a more realistic example to understand where problems could arise would be to consider a string buffer implementation. This would be a class that contains an internal buffer of characters. The class may provide several conversion constructors: a default constructor, a constructor that takes a size_t parameter representing the size of the buffer to preallocate, and a constructor that takes a pointer to char that should be used to allocate and initialize the internal buffer. Succinctly, such a string buffer could look like this:

    class string_buffer 
    { 
    public: 
      string_buffer() {} 

      string_buffer(size_t const size) {} 

      string_buffer(char const * const ptr) {} 

      size_t size() const { return ...; } 
      operator bool() const { return ...; } 
      operator char * const () const { return ...; } 
    };

Based on this definition, we could construct the following objects:

    std::shared_ptr<char> str; 
    string_buffer sb1;             // empty buffer 
    string_buffer sb2(20);         // buffer of 20 characters 
    string_buffer sb3(str.get());   
    // buffer initialized from input parameter

sb1 is created using the default constructor and thus has an empty buffer; sb2 is initialized using the constructor with a single parameter and the value of the parameter represents the size in characters of the internal buffer; sb3 is initialized with an existing buffer and that is used to define the size of the internal buffer and to copy its value into the internal buffer. However, the same definition also enables the following object definitions:

    enum ItemSizes {DefaultHeight, Large, MaxSize}; 

    string_buffer b4 = 'a'; 
    string_buffer b5 = MaxSize;

In this case, b4 is initialized with a char. Since an implicit conversion to size_t exists, the constructor with a single parameter will be called. The intention here is not necessarily clear; perhaps it should have been "a" instead of 'a', in which case the third constructor would have been called. However, b5 is most likely an error, because MaxSize is an enumerator representing an ItemSizes and should have nothing to do with a string buffer size. These erroneous situations are not flagged by the compiler in any way.

Using the explicit specifier in the declaration of a constructor, that constructor becomes an explicit constructor and no longer allows implicit constructions of objects of a class type. To exemplify this, we will slightly change the string_buffer class earlier to declare all constructors explicit:

    class string_buffer 
    { 
    public: 
      explicit string_buffer() {} 

      explicit string_buffer(size_t const size) {} 

      explicit string_buffer(char const * const ptr) {} 

      explicit operator bool() const { return ...; } 
      explicit operator char * const () const { return ...; } 
    };

The change is minimal, but the definitions of b4 and b5 in the earlier example no longer work, and are incorrect, since the implicit conversion from char or int to size_t are no longer available during overload resolution to figure out what constructor should be called. The result is compiler errors for both b4 and b5. Note that b1, b2, and b3 are still valid definitions even if the constructors are explicit.

The only way to fix the problem, in this case, is to provide an explicit cast from char or int to string_buffer:

    string_buffer b4 = string_buffer('a'); 
    string_buffer b5 = static_cast<string_buffer>(MaxSize); 
    string_buffer b6 = string_buffer{ "a" };

With explicit constructors, the compiler is able to immediately flag erroneous situations and developers can react accordingly, either fixing the initialization with a correct value or providing an explicit cast.

The following definitions are still possible (and wrong) with explicit constructors:

    string_buffer b7{ 'a' }; 
    string_buffer b8('a');

Similar to constructors, conversion operators can be declared explicit (as shown earlier). In this case, the implicit conversions from the object type to the type specified by the conversion operator are no longer possible and require an explicit cast. Considering b1 and b2, the string_buffer objects defined earlier, the following are no longer possible with explicit conversion operator bool:

    std::cout << b1 + b2 << std::endl; 
    if(b1 == b2) {}

Instead, they require explicit conversion to bool:

    std::cout << static_cast<bool>(b1) + static_cast<bool>(b2);
    if(static_cast<bool>(b1) == static_cast<bool>(b2)) {}

In this recipe, we will discuss concepts such as global functions, static functions, and variables, namespaces, and translation units. Apart from these, it is required that you understand the difference between internal and external linkage; that is key for this recipe.

When you are in a situation where you need to declare global symbols as statics to avoid linkage problems, prefer to use unnamed namespaces:

The following example shows two functions called print() in two different translation units; each of them is defined in an unnamed namespace:

    // file1.cpp 
    namespace 
    { 
      void print(std::string message) 
      { 
        std::cout << "[file1] " << message << std::endl; 
      } 
    } 

    void file1_run() 
    { 
      print("run"); 
    } 

    // file2.cpp 
    namespace 
    { 
      void print(std::string message) 
      { 
        std::cout << "[file2] " << message << std::endl; 
      } 
    } 

    void file2_run() 
    { 
      print("run"); 
    }

When a function is declared in a translation unit, it has external linkage. That means two functions with the same name from two different translation units would generate a linkage error because it is not possible to have two symbols with the same name. The way this problem is solved in C, and by some in C++ also, is to declare the function or variable static and change its linkage from external to internal. In this case, its name is no longer exported outside the translation unit, and the linkage problem is avoided.

The proper solution in C++ is to use unnamed namespaces. When you define a namespace like the ones shown above, the compiler transforms it to the following:

    // file1.cpp 
    namespace _unique_name_ {} 
    using namespace _unique_name_; 
    namespace _unique_name_ 
    { 
      void print(std::string message) 
      { 
        std::cout << "[file1] " << message << std::endl; 
      } 
    } 

    void file1_run() 
    { 
      print("run"); 
    }

First of all, it declares a namespace with a unique name (what the name is and how it generates that name is a compiler implementation detail and should not be a concern). At this point, the namespace is empty, and the purpose of this line is to basically establish the namespace. Second, a using directive brings everything from the _unique_name_ namespace into the current namespace. Third, the namespace, with the compiler-generated name, is defined as it was in the original source code (when it had no name).

By defining the translation unit local print() functions in an unnamed namespace, they have local visibility only, yet their external linkage no longer produces linkage errors since they now have external unique names.

Unnamed namespaces are also working in a perhaps more obscure situation involving templates. Template arguments cannot be names with internal linkage, so using static variables is not possible. On the other hand, symbols in an unnamed namespace have external linkage and can be used as template arguments. This problem is shown in the following example where declaring t1 produces a compiler error because the non-type argument expression has internal linkage. However, t2 is correct because Size2 has external linkage:

    template <int const& Size> 
    class test {}; 

    static int Size1 = 10; 

    namespace 
    { 
      int Size2 = 10; 
    } 

    test<Size1> t1; 
    test<Size2> t2;

In this recipe, we will discuss namespaces and nested namespaces, templates and template specializations, and conditional compilation using preprocessor macros. Familiarity with these concepts is required in order to proceed with the recipe.

To provide multiple versions of a library and let the user decide what version to use, do the following:

The following example shows a library that has two versions that clients can use:

    namespace modernlib 
    { 
      #ifndef LIB_VERSION_2 
      inline namespace version_1 
      { 
        template<typename T> 
        int test(T value) { return 1; } 
      } 
      #endif 

      #ifdef LIB_VERSION_2 
      inline namespace version_2 
      { 
        template<typename T> 
        int test(T value) { return 2; } 
      } 
      #endif 
    }

A member of an inline namespace is treated as if it was a member of the surrounding namespace. Such a member can be partially specialized, explicitly instantiated, or explicitly specialized. This is a transitive property, which means that if a namespace A contains an inline namespace B that contains an inline namespace C, then the members of C appear as they were members of both B and A and the members of B appear as they were members of A.

To better understand why inline namespaces are helpful, let's consider the case of developing a library that evolves over time from a first version to a second version (and further on). This library defines all its types and functions under a namespace called modernlib. In the first version, this library could look like this:

    namespace modernlib 
    { 
      template<typename T> 
      int test(T value) { return 1; } 
    }

A client of the library can make the following call and get back the value 1:

    auto x = modernlib::test(42);

However, the client might decide to specialize the template function test() as the following:

    struct foo { int a; }; 

    namespace modernlib 
    { 
      template<> 
      int test(foo value) { return value.a; } 
    } 

    auto y = modernlib::test(foo{ 42 });

In this case, the value of y is no longer 1, but 42 because the user-specialized function gets called.

Everything is working correctly so far, but as a library developer you decide to create a second version of the library, yet still ship both the first and the second version and let the user control what to use with a macro. In this second version, you provide a new implementation of the test() function that no longer returns 1, but 2. To be able to provide both the first and second implementations, you put them in nested namespaces called version_1 and version_2 and conditionally compile the library using preprocessor macros:

    namespace modernlib 
    { 
      namespace version_1 
      { 
        template<typename T> 
        int test(T value) { return 1; } 
      } 

      #ifndef LIB_VERSION_2 
      using namespace version_1; 
      #endif 

      namespace version_2  
      { 
        template<typename T> 
        int test(T value) { return 2; } 
      } 

      #ifdef LIB_VERSION_2 
      using namespace version_2; 
      #endif 
    }

Suddenly, the client code will break, regardless of whether it uses the first or second version of the library. That is because the test function is now inside a nested namespace, and the specialization for foo is done in the modernlib namespace, when it should actually be done in modernlib::version_1 or modernlib::version_2. This is because the specialization of a template is required to be done in the same namespace where the template was declared. In this case, the client needs to change the code like this:

    #define LIB_VERSION_2 

    #include "modernlib.h" 

    struct foo { int a; }; 

    namespace modernlib 
    { 
      namespace version_2  
      { 
        template<> 
        int test(foo value) { return value.a; } 
      } 
    }

This is a problem because the library leaks implementation details, and the client needs to be aware of those in order do the template specialization. These internal details are hidden with inline namespaces in the manner shown in the How to do it... section of this recipe. With that definition of the modernlib library, the client code with the specialization of the test() function in the modernlib namespace is no longer broken, because either version_1::test() or version_2::test() (depending on what version the client is actually using) acts as being part of the enclosing modernlib namespace when template specialization is done. The details of the implementation are now hidden to the client that only sees the surrounding namespace modernlib.

However, you should keep in mind that:

For this recipe, you should be familiar with the standard utility types std::pair and std::tuple and the utility function std::tie().

To return multiple values from a function using a compiler that supports C++17 you should do the following:

        std::tuple<int, std::string, double> find() 
        { 
          return std::make_tuple(1, "marius", 1234.5); 
        }

        auto [id, name, score] = find();

        if (auto [id, name, score] = find(); score > 1000) 
        { 
          std::cout << name << std::endl; 
        }

Structured bindings are a language feature that works just like std::tie(), except that we don't have to define named variables for each value that needs to be unpacked explicitly with std::tie(). With structured bindings, we define all named variables in a single definition using the auto specifier so that the compiler can infer the correct type for each variable.

To exemplify this, let's consider the case of inserting items in a std::map. The insert method returns a std::pair containing an iterator to the inserted element or the element that prevented the insertion, and a boolean indicating whether the insertion was successful or not. The following code is very explicit and the use of second or first->second makes the code harder to read because you need to constantly figure out what they represent:

    std::map<int, std::string> m; 

    auto result = m.insert({ 1, "one" }); 
    std::cout << "inserted = " << result.second << std::endl 
              << "value = " << result.first->second << std::endl;

The preceding code can be made more readable with the use of std::tie, that unpacks tuples into individual objects (and works with std::pair because std::tuple has a converting assignment from std::pair):

    std::map<int, std::string> m; 
    std::map<int, std::string>::iterator it; 
    bool inserted; 

    std::tie(it, inserted) = m.insert({ 1, "one" }); 
    std::cout << "inserted = " << inserted << std::endl 
              << "value = " << it->second << std::endl; 

    std::tie(it, inserted) = m.insert({ 1, "two" }); 
    std::cout << "inserted = " << inserted << std::endl 
              << "value = " << it->second << std::endl;

The code is not necessarily simpler because it requires defining in advance the objects that the pair is unpacked to. Similarly, the more elements the tuple has the more objects you need to define, but using named objects makes the code easier to read.

C++17 structured bindings elevate the unpacking of tuple elements into named objects to the rank of a language feature; it does not require the use of std::tie(), and objects are initialized when declared:

    std::map<int, std::string> m; 
    { 
      auto[it, inserted] = m.insert({ 1, "one" }); 
      std::cout << "inserted = " << inserted << std::endl 
                << "value = " << it->second << std::endl; 
    } 

    { 
      auto[it, inserted] = m.insert({ 1, "two" }); 
      std::cout << "inserted = " << inserted << std::endl 
                << "value = " << it->second << std::endl; 
    }

The use of multiple blocks in the above example is necessary because variables cannot be redeclared in the same block, and structured bindings imply a declaration using the auto specifier. Therefore, if you need to make multiple calls like in the example above and use structured bindings you must either use different variable names or multiple blocks as shown above. An alternative to that is to avoid structured bindings and use std::tie(), because it can be called multiple times with the same variables, therefore you only need to declare them once.

In C++17, it is also possible to declare variables in if and switch statements with the form if(init; condition) and switch(init; condition). This could be combined with structured bindings to produce simpler code. In the following example, we attempt to insert a new value into a map. The result of the call is unpacked into two variables, it and inserted, defined in the scope of the if statement in the initialization part. The condition of the if statement is evaluated from the value of the inserted object:

    if(auto [it, inserted] = m.insert({ 1, "two" }); inserted)
    { std::cout << it->second << std::endl; }