Morden C++ Best Practices and Low-Level Operations

This document explains each of the requested technologies and concepts in detail, with practical examples and diagrams where helpful. The topics range from advanced template techniques to fundamental language mechanics.

---

1. Variadic Templates & Parameter Packs

What they are Variadic templates allow a template to accept an arbitrary number of arguments of different types. A parameter pack is a placeholder for zero or more template arguments.

Best practices

• Use sizeof...(Args) to get the number of arguments.

• Prefer fold expressions (C++17) over recursion for simple operations.

• Use std::forward<Args>(args)... for perfect forwarding of parameter packs.

• When recursion is unavoidable, use a constexpr function with an empty pack overload.

Example

// Fold expression (C++17)
template<typename... Args>
auto sum(Args... args) {
    return (args + ...);   // unary right fold
}

// Recursive (pre-C++17)
template<typename T>
T sum(T t) { return t; }
template<typename T, typename... Args>
T sum(T t, Args... args) { return t + sum(args...); }

Diagram: Fold Expression Expansion

Fold: (args + ...) with args = 1, 2, 3
Expands to: 1 + (2 + 3)
Not: (1 + 2) + 3   // that's left fold

---

2. Move Semantics & Perfect Forwarding

Move semantics Allow transferring resources (e.g., heap memory) from temporary objects, avoiding deep copies. Implemented via rvalue references (T&&) and std::move.

Perfect forwarding Preserves the value category (lvalue/rvalue) of arguments when passing them through a function. Implemented via forwarding references (T&& in a deduced context) and std::forward.

Best practices

• Declare move constructor and move assignment as noexcept for optimal container performance.

• Use std::move to cast lvalues to rvalues (only when you intend to move).

• Use std::forward exactly with forwarding references.

• Return by value; the compiler will move local variables implicitly (C++11 and later).

Example

class Buffer {
    char* ptr;
    size_t size;
public:
    // Move constructor
    Buffer(Buffer&& other) noexcept
        : ptr(other.ptr), size(other.size) {
        other.ptr = nullptr;
        other.size = 0;
    }
    // Perfect forwarding in a factory function
    template<typename... Args>
    static Buffer create(Args&&... args) {
        return Buffer(std::forward<Args>(args)...);
    }
};

Diagram: Copy vs Move

Copy:                               Move:
std::string s1 = "hello";           std::string s2 = std::move(s1);
s1.data ──allocate/copy──> s2.data s1.data ──transfer──> s2.data
                                    s1 now empty (nullptr)

---

3. Concepts (C++20) & SFINAE

Concepts Named compile‑time predicates that constrain template parameters. They replace SFINAE with clearer syntax and better error messages.

SFINAE (Substitution Failure Is Not An Error) Older technique using decltype, std::enable_if, or void_t to conditionally enable/disable templates based on type traits.

Best practices

• Prefer concepts over SFINAE for new code.

• Define reusable concepts in headers (e.g., #include <concepts>).

• Use requires clauses directly on function or class templates.

• For SFINAE, prefer std::enable_if_t with alias templates, but now use concepts.

Example (Concepts)

#include <concepts>

template<typename T>
concept Incrementable = requires(T x) {
    ++x;
    x++;
};

template<Incrementable T>
void inc(T& x) { ++x; }

Diagram: SFINAE vs Concepts

SFINAE: Overload set includes function templates;
        ill-formed substitutions are silently discarded.
Concepts: Constraint violated → clear compile error at the point of instantiation.

---

4. CRTP (Curiously Recurring Template Pattern)

What it is A class template that takes its own derived class as a template parameter. Enables static polymorphism, mixins, and interface injection without virtual calls.

Best practices

• Use static_cast<Derived*>(this) to access derived members.

• Combine with concepts to enforce derived class interface.

• Prefer CRTP over virtual functions in performance‑critical code where the type is known at compile time.

Example

template<typename Derived>
class Addable {
public:
    friend Derived operator+(const Derived& a, const Derived& b) {
        Derived result = a;
        result += b;   // requires operator+= in Derived
        return result;
    }
};

class Vec2 : public Addable<Vec2> {
    int x, y;
public:
    Vec2& operator+=(const Vec2& other) { x += other.x; y += other.y; return *this; }
};

Diagram: CRTP static_cast

Base<Derived> ← static_cast<Derived*>(this) → Derived
      ↑                                      inherits Base<Derived>
      └──────────────────────────────────────┘

---

5. Traits, Policies, and Tag‑Types

Traits Compile‑time type information (e.g., std::is_integral, std::iterator_traits). Often implemented as templates with static members.

Policies Template parameters that customize behaviour (e.g., allocators, comparators). A policy class must satisfy a documented interface.

Tag‑types Empty types used to select overloads via tag dispatch (e.g., std::random_access_iterator_tag).

Best practices

• Use variable templates for traits: template<typename> inline constexpr bool is_integral_v = ...;

• Define policy classes with a consistent static interface.

• Use tag dispatch to choose algorithms based on iterator category.

Example (Tag Dispatch)

struct fast_tag {};
struct safe_tag {};

template<typename T>
void process(T& data, fast_tag) {
    // fast, unchecked version
}

template<typename T>
void process(T& data, safe_tag) {
    // safe, slower version
}

template<typename T, typename Tag>
void dispatch(T& data) {
    process(data, Tag{});
}

Diagram: Tag Dispatch Flow

template<typename Iter>
void advance(Iter& it, ptrdiff_t n) {
    advance_impl(it, n, 
        typename std::iterator_traits<Iter>::iterator_category{});
}
                    │
                    ▼
    (function overloads on tag parameter)

---

6. Tuples, Variants, Visit, Apply

std::tuple Fixed‑size collection of heterogeneous types. std::variant Type‑safe union; holds one of several types at a time. std::visit Applies a visitor to a variant. std::apply Unpacks a tuple into arguments to a callable.

Best practices

• Use structured bindings (C++17) to unpack tuples: auto [a, b, c] = t;

• Prefer std::variant over raw unions; ensure all alternative types are cheap to move/destroy.

• Use generic lambdas as visitors: std::visit([](auto&& arg){ ... }, v);

• Use std::apply with std::make_from_tuple to construct objects.

Example

std::tuple<int, double, std::string> t{42, 3.14, "hello"};

// Apply a lambda to each element (C++17)
std::apply([](auto&&... args) {
    ((std::cout << args << ' '), ...);   // fold expression
}, t);

std::variant<int, std::string> v = "C++";
std::visit([](auto&& arg) {
    std::cout << arg;
}, v);

Diagram: Tuple & Variant Memory Layout

std::tuple<int, char, double>
[ int ][ char ][ double ]   // contiguous, but alignment may add padding

std::variant<int, double, std::string>
[ tag ][          union           ]
 tag = current type index; union large enough for largest type.

---

7. pImpl Idiom (Pointer to Implementation)

What it is Hide implementation details by storing only a pointer to a forward‑declared struct in the public header. Reduces compilation dependencies and improves build times.

Best practices

• Use std::unique_ptr<Impl>; remember to declare destructor in .cpp because Impl is incomplete at header.

• Alternatively, std::shared_ptr<Impl> with custom deleter.

• Provide non‑inline special member functions defined after Impl is complete.

• Sometimes called “compiler firewall”.

Example

// widget.h
class Widget {
public:
    Widget();
    ~Widget();   // declared, not defaulted
    void draw();
private:
    struct Impl;
    std::unique_ptr<Impl> pImpl;
};

// widget.cpp
struct Widget::Impl {
    std::string name;
    int id;
};

Widget::Widget() : pImpl(std::make_unique<Impl>()) {}
Widget::~Widget() = default;   // Impl complete here
void Widget::draw() { /* use pImpl->... */ }

Diagram: pImpl Structure

Header (.h):          Implementation (.cpp):
class Widget          struct Widget::Impl {
    unique_ptr<Impl>      // actual members
};                    };
      │                    ↑
      └── pointer (opaque) ┘

---

8. Lambdas

What they are Anonymous function objects that can capture variables from the surrounding scope. Syntactic sugar for a compiler‑generated functor.

Best practices

• Use auto parameters for generic lambdas (C++14).

• Avoid default capture modes ([&], [=]) in code with potential dangling references; prefer explicit capture.

• Use init‑capture (C++14) to capture move‑only types: [p = std::make_unique<int>(42)]{}

• Lambdas are constexpr by default if possible (C++17).

• Mark mutable when the lambda modifies captured copies.

Example

auto add = [](auto x, auto y) { return x + y; }; // generic lambda

auto unique_ptr_capture = [ptr = std::make_unique<int>(10)] {
    return *ptr;
};

auto counter = [i = 0]() mutable { return i++; }; // stateful lambda

Diagram: Lambda Expansion

auto l = [x](int y) { return x + y; };

// Compiler transforms to:
class __lambda_123 {
    int x;
public:
    __lambda_123(int x_) : x(x_) {}
    auto operator()(int y) const { return x + y; }
};

---

9. Custom Streaming Operators

What they are Overload operator<< for std::ostream to enable output of user‑defined types.

Best practices

• Define as non‑member function in the same namespace as the type (ADL).

• Return std::ostream& to allow chaining.

• If the type has private members, declare it as friend inside the class.

• Keep output format simple; avoid side effects that may fail.

Example

struct Point { int x, y; };

std::ostream& operator<<(std::ostream& os, const Point& p) {
    os << '(' << p.x << ", " << p.y << ')';
    return os;
}
// Now std::cout << Point{1,2};

---

10. constexpr

What it is Specifies that a function or variable can be evaluated at compile time. C++11: limited to single return statement. C++14: relaxed. C++17: lambdas, if constexpr. C++20: virtual functions, try‑catch, dynamic allocation, etc.

Best practices

• Mark functions constexpr if they can be evaluated at compile time.

• Use consteval (C++20) for functions that must be evaluated at compile time.

• Prefer constexpr variables over macros for compile‑time constants.

• C++20: constexpr destructors for literal types.

Example

constexpr int factorial(int n) {
    int result = 1;
    for (int i = 2; i <= n; ++i) result *= i; // C++14 allowed
    return result;
}
static_assert(factorial(5) == 120);

Diagram: Compile‑time vs Runtime

Source code
      │
      ├─ constexpr function called with constant arguments ──► compile-time evaluation → constant
      │
      └─ called with runtime variables ──► normal runtime call

---

11. auto

What it is Type deduction placeholder. Used for variables, return types, function parameters (C++20), and non‑type template parameters (C++17).

Best practices

• Use auto to avoid repeating obvious types and to guarantee correct type (especially for iterators).

• Combine with const, &, && to specify desired semantics: const auto&, auto&&.

• For return types that depend on expression, use decltype(auto) to preserve references.

• Avoid auto when the type is not obvious from context (e.g., auto x = foo(); is fine; auto x = 42; is less clear but acceptable).

Example

std::vector<int> v = {1,2,3};
for (const auto& elem : v) { /* ... */ }

decltype(auto) foo() {
    static int x = 42;
    return (x);   // returns int& because (x) is lvalue expression
}

---

12. Lambdas and Macro Hackery

Macro hackery refers to using preprocessor macros to generate lambdas or to replace lambda syntax. Macros are generally discouraged because they are not scoped and can cause ODR violations.

Best practices

• Prefer lambdas over macros for callable objects.

• If macros are unavoidable (e.g., __FILE__, __LINE__), generate minimal code and wrap the macro body in a lambda to avoid multiple evaluations.

• Never use macros to generate names that cross translation units without caution.

Example (macro generating a lambda)

#define TRACE(expr)                                               \
    do {                                                          \
        auto&& __tmp = (expr);                                    \
        std::cout << #expr << " = " << __tmp << " at "           \
                  << __FILE__ << ':' << __LINE__ << '\n';         \
    } while(0)

Diagram: Macro vs Lambda

Macro: pure text substitution – no scoping, no type safety.
Lambda: compiler‑generated functor – scoped, typed, captures.

---

13. Sequencing

What it is Order of evaluation of expressions, subexpressions, and function arguments. C++17 introduced several guaranteed sequencing rules to eliminate undefined behaviour in many cases.

C++17 guarantees

• Postfix expressions are evaluated left‑to‑right.

• Assignment operators are evaluated right‑to‑left (rhs before lhs).

• Shift operators (<<, >>) are left‑to‑right.

• Function arguments are evaluated in unspecified order, but all side effects are sequenced before the function call.

• No interleaving in a.b, a->b, a.*b, a->*b.

Best practices

• Do not write code that modifies the same variable multiple times between sequence points.

• Use parentheses to clarify intent, not to force evaluation order (except for ternary, logical, comma).

• Prefer split statements for complex expressions.

Example of undefined behaviour (pre‑C++17)

i = i++ + i; // UB (multiple unsequenced modifications)

---

14. Aliasing

What it is Aliasing occurs when two pointers/references refer to the same memory location. The strict aliasing rule allows the compiler to assume that pointers of different types (except char*, unsigned char*, std::byte*) do not alias.

Best practices

• Use std::bit_cast (C++20) for type‑punning.

• Use memcpy or std::memcpy to copy bytes between types.

• Avoid reinterpret_cast for accessing an object as a different type.

• Compile with -fstrict-aliasing -Wstrict-aliasing to detect violations.

Example

// Safe type punning with bit_cast (C++20)
float f = 3.14f;
uint32_t i = std::bit_cast<uint32_t>(f);

Diagram: Aliasing Violation

int x = 42;
float* p = reinterpret_cast<float*>(&x); // violates strict aliasing
*p = 3.14f; // UB

---

15. Global/Namespace Scope vs Stack vs Heap

Memory regions

• Static storage (global/namespace scope, static locals): Lifetime = entire program; initialized before main, destroyed after main.

• Stack (automatic storage): Local variables; LIFO, fast, limited size.

• Heap (dynamic storage): Allocated via new/malloc, managed manually or via smart pointers; larger capacity, slower.

Best practices

• Minimize non‑local static objects to avoid static initialization order fiasco. Use constexpr or function‑local statics.

• Prefer stack allocation when size and lifetime are known at compile time.

• Use smart pointers (std::unique_ptr, std::shared_ptr) for heap allocation.

Diagram: Typical Memory Layout

High addresses
    ┌─────────────────┐
    │     Stack       │ ← grows downward
    │ (local vars)    │
    ├─────────────────┤
    │       ↓         │
    │   (free space)  │
    ├─────────────────┤
    │       ↑         │
    │     Heap        │ ← grows upward
    ├─────────────────┤
    │  Uninitialized  │
    │  Data (BSS)     │
    ├─────────────────┤
    │  Initialized    │
    │  Data (DS)      │
    ├─────────────────┤
    │  Text (code)    │
    └─────────────────┘
Low addresses

---

16. Smart Pointers

std::unique_ptr Exclusive ownership; zero overhead over raw pointer. Movable, not copyable. Use std::make_unique.

std::shared_ptr Shared ownership via reference counting; control block holds count and deleter. Use std::make_shared.

std::weak_ptr Non‑owning observer of shared_ptr; breaks cycles. Lock to obtain shared_ptr.

Best practices

• Prefer std::unique_ptr by default.

• Use std::shared_ptr only when ownership is truly shared.

• Avoid std::shared_ptr for small objects or performance‑critical paths due to control block overhead.

• Never use raw new/delete; always use std::make_unique/std::make_shared.

Example

auto p = std::make_unique<int>(42);     // unique_ptr
auto s = std::make_shared<double>(3.14); // shared_ptr

std::weak_ptr<double> w = s;            // weak_ptr
if (auto locked = w.lock()) {
    // use *locked
}

Diagram: Shared_ptr Control Block

shared_ptr<T>                     Control Block
┌─────────────┐                  ┌─────────────┐
│ ptr to T    │ ────────────────►│ strong refs │
│ ptr to ctrl │ ────┐           │ weak refs   │
└─────────────┘     │           │ deleter     │
                    │           │ allocator   │
                    └──────────►│ T object?   │ (if make_shared)
                                └─────────────┘

---

17. Virtual Dispatch

What it is Runtime polymorphism via virtual functions. Each polymorphic class has a vtable (array of function pointers). Each object has a vptr pointing to its class’s vtable. Calls are resolved by dereferencing the vtable at runtime.

Best practices

• Mark overriding functions with override.

• Destructor of polymorphic base should be virtual.

• Use final on classes or virtual functions to prevent further overriding.

• Avoid calling virtual functions in constructors/destructors (no polymorphic behaviour).

Example

class Base {
public:
    virtual void draw() const { std::cout << "Base\n"; }
    virtual ~Base() = default;
};

class Derived : public Base {
public:
    void draw() const override { std::cout << "Derived\n"; }
};

Diagram: Vtable and Vptr

Derived d
[ vptr ] ──► Derived vtable
[ ...   ]     [ type_info ]
              [ Derived::draw ]
              [ ~Derived()    ]

---

18. Translation Units, ODR, extern/static/inline, Anonymous Namespaces

Translation unit (TU) A source file after preprocessing; each .cpp plus its #included headers.

One Definition Rule (ODR) Exactly one definition of each non‑inline function/variable across the entire program, except:

• Inline functions/variables can be defined in multiple TUs (must be identical).

• Class definitions, templates, etc., can appear in multiple TUs (must be identical).

Linkage specifiers

• extern "C"/extern "C++": language linkage.

• extern on variable: declares without defining; external linkage.

• static at namespace scope: internal linkage (TU‑local).

• inline: allows multiple definitions; often used in headers.

Anonymous namespaces Give internal linkage to all contents; preferred over static for TU‑local entities.

Best practices

• Use header guards or #pragma once.

• Use anonymous namespaces for TU‑local functions/variables.

• Place inline functions/variables in headers.

• Avoid non‑volatile non‑inline global variables across TUs.

Diagram: Translation Units and Linking

a.cpp ──┬─► a.o ──┐
b.cpp ──┴─► b.o ──┼─► linker ──► executable
...                │
libc.a ────────────┘

---

19. Operator Overloading

What it is Giving special meanings to operators for user‑defined types.

Best practices

• Preserve natural semantics (e.g., + commutative, * associative).

• Overload as non‑member if the left operand is not your type (e.g., ostream& operator<<).

• For binary operators that need access to private members, define them as friend inside the class.

• Use explicit for conversion operators to avoid surprising implicit conversions.

Example

class Fraction {
    int num, den;
public:
    Fraction operator+(const Fraction& other) const;
    bool operator==(const Fraction& other) const;
    explicit operator double() const { return double(num)/den; }
};

---

20. RAII (Resource Acquisition Is Initialization)

What it is A programming idiom where resource acquisition (memory, file handle, mutex) is tied to object lifetime: acquire in constructor, release in destructor. Ensures exception‑safety and automatic cleanup.

Best practices

• Every resource should be owned by a RAII object.

• Destructors should never throw; mark them noexcept.

• Use standard RAII wrappers (std::vector, std::string, std::unique_ptr, std::lock_guard).

• For custom resources, implement the Rule of Five (destructor, copy/move constructor, copy/move assignment) or use std::unique_ptr with custom deleter.

Example

void process_file(const char* filename) {
    std::ifstream file(filename);   // RAII: opens file in constructor
    if (file) {
        std::string line;
        std::getline(file, line);
        // file automatically closed at end of scope
    }
}

Diagram: RAII Lifecycle

Scope entry:
    ├─ Constructor acquires resource (e.g., locks mutex, opens file)
    │
    └─ Scope exit (normal or via exception):
        └─ Destructor releases resource (closes file, unlocks mutex)

---

This concludes the comprehensive explanation of the requested modern C++ features and low‑level operations. Each topic includes key principles, best practices, examples, and diagrams where appropriate. Mastery of these concepts enables writing efficient, maintainable, and safe C++ code.