Modern C++

• Distinguish between () and {} when constructing object.

  • C++’s most vexing parse

  • In the most of the time, use {} to create the object.

  • But {} will also be treated as std::initializer_listif the class has a constructor Ci that takes std::initializer_list as the argument. And Ci will override the other initializers when you construct the object with {} brackets.

    • It will prevent narrowing conversions, for example a constructor like this cannot accept a list of int values. for more details, check https://en.cppreference.com/w/cpp/language/list_initialization

    class Widget {
    	public:
    		Widget(std::initializer_list<bool> il);
    };
    
    Widget w{10, 2}; // Error, 
    

    

    • Another example, std::vector has two initializers, creating a vector with given size and value , and it also contains a std::list_initializer, but if you write std::vector<int> v{3, 2} . The result is {3, 2} instead of {2, 2, 2}. You need to use braces () to call the other constructor. which is very confusing.

    <aside> ⚠️ When writing your own constructor, be very careful if you want to add the std::list_initializer since it may break the old code.

    </aside>

• Prefer nullptr to 0 and NULL

  • nullptr_t is not a pointer type, nullptr_t is a type of the null pointer literal.
  • When writing template code, 0 and NULL cannot be deducted to a pointer type.

• Prefer alias declarations to typedefs.

  • use using directive instead of typedef to simplify defining a function pointer type.
  • when doing C++ template meta programming, use using instead of typedef
  • [ ] C++ type traits.

• Use enum class instead of unscoped enum. The enum class is much more strongly typed.

  • forward declaration: https://en.cppreference.com/w/cpp/language/class

• Use = delete to reject invoking of a specific function (copy constructor, fn with specific arguments etc).

• For a override function, the name, parameter list, const-ness, must be identical to the base function. And after cpp11, the reference identifer must be identical as well.

  • Declare the override function explicitly override to ensure the compiler can help you find override-related issues (as mentioned above)

• Prefer to use cbegin, cend when the iterator doesn’t need to do any modification to the data.

• Using noexcept when the function doesn’t emit exception

  • Esp. when the function is a moving ctor. std::vector function push_back can be optimized to use std::move when resizing the vector ONLY IF the move constructor has noexcept keyword.
  • dtor by default is implicitly noexcept

• Use constexpr whenever possible

  1. constexpr on a class/object means the object’s value and type is known at the compile time.
  2. But the above mentioned fact is not always true,
  3. When declaring a function return type as constexpr , the following limitations need to be met
     1. All the arguments should be literal types
        1. User can even define literal types (a constructor that has constexpr)
     2. If the function is evaluated in someplace that need to know the value during compile time (e.g template argument). The return value of the constexpr function should also be known at compile time
  4. C++ 11 constexpr functions may only contain one single statement return ..., while C++ 14 allows

• mutable keyword

  • A member marked as mutable can be modified even in a object/function declared as const
    • In the following code snippet, get modifies mutex m but the function is still considered const since m is muatble
  • Another common rule: “M&M rule” mutable and mutex always go together

  class ThreadsafeCounter {
    mutable std::mutex m; // The "M&M rule": mutable and mutex go together
    int data = 0;
   public:
    int get() const {
      std::lock_guard<std::mutex> lk(m);
      return data;
    }
    void inc() {
      std::lock_guard<std::mutex> lk(m);
      ++data;
    }
  };
  

• Since const functions might be very likely used in concurrent executions (maybe in the future), make sure your const functions are thread safe (i.e using mutex, atomic to protect concurrent mutable variable modification)

• Special member function generation (SKIPPED)

Smart Pointers

• Unique Pointer

  • Check the code snippet here, including unique ptr conversion to shared_ptr, custom deleter, size of unique_ptr.

  Compiler Explorer - C++ (x86-64 gcc 12.1)

  • unique_ptr can have custom deleters, when using custom deleters, please avoid using capture and use stateless lambda whenever possible. This will make the size of unique_ptr the same as normal raw pointers.
    • The type of the custom deleter is a function pointer with an argument of the Struct/Class*. Check the example above.
  • unique_ptr is an move-only type. It cannot be copied.

• Shared Pointer

  • Shared Pointer shall NEVER be constructed from a raw pointer
  • shared_ptr is constructed with a raw pointer and a “control block”
    • The control block contains information such as reference_count, custom deleter, etc
    • When creating a shared_ptr from a new object. It will allocate a “control block”
    • When modify the “reference_count” of the shared_ptr , atomic instructions are required.
  • Undefined behaviors
    • shared pointers that related to the same object have more than 1 control block will cause undefined behavior
    • When using shared_from_this if the object doesn’t have a shared pointer pointed to it will cause undefined behavior

• Weak Pointer