Zero-Overhead Abstraction

C++ is built on a fundamental principle: “What you don’t use, you don’t pay for. And what you do use, you couldn’t hand code any better.” This zero-overhead abstraction principle distinguishes C++ from its contemporaries. Unlike Java or C#, which enforce garbage collection overhead, C++ provides high-level abstractions that compile down to machine code equivalent to hand-optimized C.

The language offers three programming paradigms that coexist seamlessly:

1. Procedural: Direct manipulation of data structures and algorithms
2. Object-Oriented: Classes, inheritance, polymorphism, encapsulation
3. Generic: Templates and compile-time metaprogramming

The Evolution of C++

C++ has evolved dramatically since Bjarne Stroustrup’s original design in 1979. Understanding this evolution is crucial for reading existing codebases and writing idiomatic modern code.

The Compilation Model

Unlike interpreted languages, C++ undergoes a multi-stage compilation process that enables aggressive optimization.

Name Mangling and the One Definition Rule

C++ supports function overloading, templates, and namespaces, which requires name mangling: the compiler transforms human-readable names into unique symbols. For example, void foo(int) might become _Z3fooi in the object file.

The One Definition Rule (ODR) states that every entity can have only one definition across all translation units. Violating ODR results in undefined behavior, though linkers often fail to detect violations.

Type System and Static Polymorphism

C++ is statically typed with strong type checking at compile time. However, it also provides mechanisms for compile-time polymorphism through templates, eliminating runtime dispatch overhead.

// Runtime polymorphism (virtual dispatch)
class Animal { virtual void speak() = 0; };
class Dog : public Animal { void speak() override; };

// Compile-time polymorphism (template instantiation)
template<typename T>
void process(T& obj) { obj.speak(); }

The template version generates specialized code for each type, enabling inlining and optimization impossible with virtual functions.

Memory Model

C++ provides direct control over memory layout and lifetime. Unlike garbage-collected languages, C++ uses deterministic destruction through RAII (Resource Acquisition Is Initialization): resources are tied to object lifetimes.

Modern C++ heavily favors automatic storage with smart pointers (unique_ptr, shared_ptr) managing dynamic memory automatically.

#include <iostream>

int () {
    std::cout << "Modern C++ initialized\n";
    return 0;
}

Undefined Behavior and the Abstract Machine

Like C, C++ defines behavior in terms of an abstract machine. Operations outside the specification result in undefined behavior (UB), where the compiler may assume such cases never occur and optimize accordingly.

Common sources of UB:

• Dereferencing null or dangling pointers
• Data races (concurrent modification without synchronization)
• Signed integer overflow
• Accessing objects after their lifetime ends

Modern compilers include sanitizers (AddressSanitizer, UndefinedBehaviorSanitizer) to detect UB at runtime during development.

Fundamental Types and Type Categories

C++ provides a rich type system that balances low-level control with high-level abstractions. Every type belongs to one of several categories, each with distinct properties regarding copying, lifetime, and memory representation.

Built-in Fundamental Types

C++ guarantees size relationships: sizeof(char) ≤ sizeof(short) ≤ sizeof(int) ≤ sizeof(long) ≤ sizeof(long long). However, exact sizes are implementation-defined. Use <cstdint> for fixed-width types: int32_t, uint64_t, etc.

Type Deduction with auto

C++11 introduced auto for automatic type deduction, reducing verbosity while maintaining static typing. The compiler deduces types from initializers at compile time—there’s no runtime overhead.

auto x = 42;              // int
auto y = 3.14;            // double
auto z = "hello";         // const char*
auto ptr = new int{5};    // int*

// Complex types become manageable
auto it = vec.begin();    // std::vector<T>::iterator
auto lambda = [](int x) { return x * 2; };  // Closure type

Type Deduction Rules

The deduction follows template argument deduction rules with some exceptions:

• Reference collapse: auto& preserves lvalue references
• const stripping: auto removes top-level const (use const auto)
• Array decay: Arrays decay to pointers unless auto&

int arr[5] = {1,2,3,4,5};
 p = arr;  // Deduces to int*
auto& r = arr;  // Deduces to int(&)[5]

decltype: Inspecting Expression Types

While auto deduces from initializers, decltype queries the type of any expression without evaluating it.

int x = 10;
decltype(x) y = 20;        // y is int

int& getRef();
decltype(getRef()) z = x;  // z is int&

// Combining auto and decltype (C++14 return type deduction)
auto func(int x) -> decltype(x * 2) {
    return x * 2;  // Return type is int
}

C++14 added decltype(auto) for perfect forwarding of return types:

template<typename Container>
decltype(auto) getElement(Container& c, size_t i) {
    return c[i];  // Preserves reference if container returns reference
}

Const Correctness

The const qualifier is fundamental to C++‘s type system, enabling the compiler to enforce immutability guarantees and enable optimizations.

Const Variables

const int max_retries = 3;  // Cannot be modified
// max_retries = 5;  // Compile error

int const alt_syntax = 5;  // Equivalent to const int

Const Pointers vs Pointer-to-Const

The placement of const determines what is immutable:

int value = 10;

const int* ptr1 = &value;  // Pointer to const int (can't modify *ptr1)
int* const ptr2 = &value;  // Const pointer to int (can't modify ptr2)
const int* const ptr3 = &value;  // Both const

*ptr1 = 20;  // Error: can't modify through ptr1
ptr1 = nullptr;  // OK: pointer itself is mutable

*ptr2 = 20;  // OK: can modify through ptr2
ptr2 = nullptr;  // Error: pointer itself is const

Mnemonic: Read right-to-left. const int* is “pointer to const int.”

Const Member Functions

Member functions can be marked const, promising not to modify object state:

class Point {
    int x_, y_;
public:
    int getX() const { return x_; }  // Doesn't modify object
    void setX(int x) { x_ = x; }     // Modifies object
};

const Point p{10, 20};
p.getX();  // OK
// p.setX(5);  // Error: can't call non-const method on const object

Type Aliases and Type Identity

C++11 introduced using for type aliases, superseding typedef:

// Old style (C++98)
typedef std::vector<int> IntVector;
typedef void (*FunctionPtr)(int);

// Modern style (C++11+)
using IntVector = std::vector<int>;
using FunctionPtr = void(*)(int);

// Template aliases (only possible with using)
template<typename T>
using Vec = std::vector<T>;

Vec<int> v;  // Equivalent to std::vector<int>

Signed vs Unsigned: A Design Choice

Integer types can be signed or unsigned. Mixing them in expressions causes implicit conversions that can be surprising:

int signed_val = -1;
unsigned int unsigned_val = 1;

if (signed_val < unsigned_val) {
    // This branch is NOT taken!
    // -1 converts to a large unsigned value
}

Best Practice: Prefer signed types for arithmetic, use unsigned only for bit manipulation or when the domain is truly non-negative (e.g., array indices—though even this is debated).

Function Overloading and Resolution

Unlike C, C++ allows multiple functions with the same name but different parameter lists. The compiler selects the appropriate overload through overload resolution at compile time based on argument types.

void print(int x) { std::cout << "int: " << x; }
void print(double x) { std::cout << "double: " << x; }
void print(const char* x) { std::cout << "string: " << x; }

print(42);      // Calls print(int)
print(3.14);    // Calls print(double)
print("hello"); // Calls print(const char*)

Overload Resolution Rules

The compiler follows a precise algorithm:

1. Exact match: Argument type matches parameter exactly
2. Promotion: Integral promotions (char → int) or float → double
3. Standard conversion: Numeric conversions, pointer conversions
4. User-defined conversion: Via conversion operators or constructors
5. Ellipsis match: Variadic functions (least preferred)

If multiple functions match at the same level, the call is ambiguous and compilation fails.

void process(int x) { }
void process(double x) { }

process(42L);  // Error: ambiguous (long can convert to int or double)

void func(int) { }
void func(double) { }
void func(const char*) { }

func();  // Calls func(int) - exact match

Default Arguments

Functions can specify default values for trailing parameters. Defaults are evaluated at call site, not function definition.

void configure(int timeout = 30, bool verbose = false);

configure();           // configure(30, false)
configure(60);         // configure(60, false)
configure(60, true);   // configure(60, true)
// configure(, true);  // Error: can't skip non-trailing arguments

Best Practice: Declare defaults in header files (declarations), not source files (definitions). This ensures callers see the defaults.

// header.hpp
void setup(int port = 8080);

// source.cpp
void setup(int port) {  // No default here
    // implementation
}

Inline Functions and ODR

The inline keyword suggests the compiler should substitute the function body at call sites, eliminating call overhead. Modern compilers ignore this hint and inline based on optimization heuristics.

However, inline has a critical semantic meaning: it relaxes the One Definition Rule, allowing identical definitions in multiple translation units.

// header.hpp
inline int square(int x) {
    return x * x;
}
// Can be included in multiple .cpp files without linker errors

Modern Usage: inline is essential for defining functions in headers, especially templates and constexpr functions (implicitly inline).

Function Templates

Templates enable generic programming by allowing functions to operate on any type satisfying certain requirements.

template<typename T>
T max(T a, T b) {
    return (a > b) ? a : b;
}

auto x = max(10, 20);        // T = int
auto y = max(3.14, 2.71);    // T = double
auto z = max<long>(5, 10);   // Explicit T = long

Template Argument Deduction

The compiler deduces template parameters from function arguments. Deduction fails if types are ambiguous:

template<typename T>
void process(T a, T b) { }

process(10, 20);     // OK: T = int
process(10, 3.14);   // Error: T is int or double?
process<double>(10, 3.14);  // OK: explicit T = double

Template Specialization

You can provide specialized implementations for specific types:

template<typename T>
T zero() { return T{}; }

template<>
const char* zero<const char*>() { return ""; }

Trailing Return Types

C++11 allows return type after parameter list, useful when return type depends on parameters:

template<typename T, typename U>
auto add(T t, U u) -> decltype(t + u) {
    return t + u;
}

C++14 simplified this with return type deduction:

template<typename T, typename U>
auto add(T t, U u) {
    return t + u;  // Type deduced from return statement
}

constexpr Functions

Functions marked constexpr can execute at compile time if arguments are constant expressions:

constexpr int factorial(int n) {
    return (n <= 1) ? 1 : n * factorial(n - 1);
}

constexpr auto result = factorial(5);  // Computed at compile time
int arr[factorial(4)];  // Array size must be compile-time constant

C++14 relaxed restrictions, allowing loops and multiple statements in constexpr functions.

References: Aliases with Semantics

References are aliases to existing objects, unlike pointers which are objects themselves. C++ provides two kinds: lvalue references (T&) and rvalue references (T&&, C++11).

int x = 10;
int& ref = x;   // Lvalue reference to x
ref = 20;       // Modifies x

int* ptr = &x;  // Pointer is a separate object
*ptr = 30;      // Modifies x through pointer

Key Properties of References

1. Must be initialized: Unlike pointers, references cannot be null or uninitialized
2. Cannot be rebound: Once bound, a reference always refers to the same object
3. No separate storage: References typically compile to pointers but have different semantics
4. No reference to reference: int& & is illegal (but see reference collapsing)

int a = 5;
int& r1 = a;
// int& r2;     // Error: must be initialized
// r1 = b;      // This assigns b's value to a, doesn't rebind r1

Value Categories: lvalues and rvalues

Every C++ expression belongs to a value category. The fundamental distinction:

• lvalue: Has persistent identity (name, memory address)
• rvalue: Temporary, about to be destroyed

int x = 10;    // x is an lvalue
int* p = &x;   // OK: can take address of lvalue

// int* p = &10;  // Error: can't take address of rvalue
// int& r = 42;   // Error: lvalue ref can't bind to rvalue

C++11 introduced finer categories:

Rvalue References and Move Semantics

Rvalue references (T&&) bind to temporaries, enabling move semantics: transferring resources instead of copying.

std::string s1 = "hello";
std::string s2 = s1;              // Copy: s1 still valid
std::string s3 = std::move(s1);   // Move: s1 left in valid but unspecified state

void process(std::string&& s) {
    // s is an rvalue reference (but s itself is an lvalue!)
}

process(std::string("temp"));     // OK: binds to temporary
process(std::move(s2));           // OK: std::move casts to rvalue
// process(s2);                   // Error: lvalue can't bind to &&

The lvalue-rvalue Paradox

Inside a function, an rvalue reference parameter is itself an lvalue (it has a name):

void func(std::string&& s) {
    std::string copy = s;            // Copy, not move (s is lvalue)
    std::string moved = std::move(s); // Move (explicitly cast to rvalue)
}

Const lvalue References: Universal Binding

A const T& can bind to both lvalues and rvalues, making it perfect for read-only parameters:

void print(const std::string& s) {  // Accepts anything
    std::cout << s;
}

std::string str = "hello";
print(str);              // OK: binds to lvalue
print("world");          // OK: binds to temporary
print(str + " world");   // OK: binds to temporary result

This is why pre-C++11 code used const T& everywhere: it’s the only reference type that accepts both lvalues and rvalues.

Reference Collapsing Rules

When references are formed through templates or typedef, C++ applies reference collapsing:

T& &   → T&
T& &&  → T&
T&& &  → T&
T&& && → T&&

Rule: An rvalue reference to an rvalue reference becomes rvalue reference; everything else becomes lvalue reference.

template<typename T>
void wrapper(T&& arg) {  // Forwarding reference (see next section)
    // If T is int&, then T&& becomes int& (reference collapsing)
    // If T is int, then T&& is int&&
}

Forwarding References (Universal References)

In template contexts, T&& has special meaning—it’s a forwarding reference that can bind to anything:

template<typename T>
void forward_wrapper(T&& arg) {  // Forwarding reference
    target(std::forward<T>(arg));  // Perfect forwarding
}

int x = 10;
forward_wrapper(x);        // T = int&, arg is int&
forward_wrapper(10);       // T = int, arg is int&&

std::forward<T> preserves the value category: forwards lvalues as lvalues, rvalues as rvalues.

int x = 5;
int& r = x;
r = 10;
std::cout << ;  // Outputs 10

Classes: User-Defined Types

Classes are the foundation of object-oriented programming in C++. They combine data (members) and behavior (methods) into cohesive types with controlled access.

class Point {
private:
    double x_, y_;  // Data members (by convention, trailing underscore)
    
public:
    Point(double x, double y) : x_(x), y_(y) {}  // Constructor
    
    double distance() const {  // Const member function
        return std::sqrt(x_ * x_ + y_ * y_);
    }
    
    void setX(double x) { x_ = x; }  // Mutator
    double getX() const { return x_; }  // Accessor
};

Access Specifiers

C++ provides three access levels:

• private: Accessible only within the class
• protected: Accessible within the class and derived classes
• public: Accessible everywhere

Default access: class defaults to private, struct defaults to public.

class MyClass {
    int private_by_default;
public:
    int explicitly_public;
};

struct MyStruct {
    int public_by_default;
private:
    int explicitly_private;
};

Convention: Use class for types with invariants requiring encapsulation; use struct for passive data containers (POD types).

Constructors and Initialization

Constructors initialize objects. C++ provides several kinds:

Default Constructor

class Widget {
public:
    Widget() : value_(0) {}  // Default constructor
private:
    int value_;
};

Widget w;  // Calls default constructor

Parameterized Constructor

class Point {
public:
    Point(double x, double y) : x_(x), y_(y) {}
private:
    double x_, y_;
};

Point p(3.0, 4.0);  // Direct initialization
Point q = {5.0, 6.0};  // Aggregate initialization (C++11)

Member Initializer Lists

Always prefer initializer lists over assignment in constructor body:

class Container {
    std::string name_;
    std::vector<int> data_;
public:
    // Good: Direct initialization
    Container(std::string n) : name_(n), data_(100) {}
    
    // Bad: Default construction then assignment
    // Container(std::string n) { name_ = n; data_.resize(100); }
};

Reasons:

1. Initialization is generally more efficient than assignment
2. Const and reference members must use initializer lists
3. Base classes and members without default constructors require it

Delegating Constructors (C++11)

Constructors can delegate to other constructors:

class Rectangle {
    double width_, height_;
public:
    Rectangle(double w, double h) : width_(w), height_(h) {}
    Rectangle() : Rectangle(0, 0) {}  // Delegates to above
};

Destructors and RAII

Destructors execute when objects are destroyed (scope exit, delete, exception). They’re the foundation of RAII (Resource Acquisition Is Initialization): tying resource lifetime to object lifetime.

class FileHandle {
    FILE* file_;
public:
    FileHandle(const char* path) : file_(fopen(path, "r")) {
        if (!file_) throw std::runtime_error("Failed to open");
    }
    
    ~FileHandle() {
        if (file_) fclose(file_);  // Always cleanup
    }
    
    // Prevent copying (for now)
    FileHandle(const FileHandle&) = delete;
    FileHandle& operator=(const FileHandle&) = delete;
};

void process() {
    FileHandle f("data.txt");
    // Use file...
}  // Destructor automatically closes file, even if exceptions thrown

Special Member Functions

The compiler auto-generates certain functions if not user-declared:

1. Default constructor (if no constructors declared)
2. Destructor
3. Copy constructor: T(const T&)
4. Copy assignment: T& operator=(const T&)
5. Move constructor: T(T&&) (C++11)
6. Move assignment: T& operator=(T&&) (C++11)

The Rule of Zero

Best Practice: If you can, don’t declare any of the special members. Let the compiler generate them. Use standard library types that manage resources correctly.

class Good {
    std::string name_;
    std::vector<int> data_;
    // Compiler-generated special members are correct
};

The Rule of Three/Five

If you declare any of destructor, copy constructor, or copy assignment, you should probably declare all three (Rule of Three). In modern C++, also declare move constructor and move assignment (Rule of Five).

class Buffer {
    char* data_;
    size_t size_;
public:
    // Constructor
    Buffer(size_t s) : data_(new char[s]), size_(s) {}
    
    // Destructor
    ~Buffer() { delete[] data_; }
    
    // Copy constructor
    Buffer(const Buffer& other) : data_(new char[other.size_]), size_(other.size_) {
        std::copy(other.data_, other.data_ + size_, data_);
    }
    
    // Copy assignment
    Buffer& operator=(const Buffer& other) {
        if (this != &other) {
            delete[] data_;
            size_ = other.size_;
            data_ = new char[size_];
            std::copy(other.data_, other.data_ + size_, data_);
        }
        return *this;
    }
    
    // Move constructor
    Buffer(Buffer&& other) noexcept : data_(other.data_), size_(other.size_) {
        other.data_ = nullptr;
        other.size_ = 0;
    }
    
    // Move assignment
    Buffer& operator=(Buffer&& other) noexcept {
        if (this != &other) {
            delete[] data_;
            data_ = other.data_;
            size_ = other.size_;
            other.data_ = nullptr;
            other.size_ = 0;
        }
        return *this;
    }
};

However, prefer std::vector<char> and Rule of Zero!

Operator Overloading: Custom Type Semantics

C++ allows redefining operators for user-defined types, enabling natural syntax for custom abstractions. Operators are functions with special names: operator+, operator[], operator<<, etc.

class Complex {
    double real_, imag_;
public:
    Complex(double r = 0, double i = 0) : real_(r), imag_(i) {}
    
    // Member operator
    Complex operator+(const Complex& other) const {
        return Complex(real_ + other.real_, imag_ + other.imag_);
    }
    
    Complex& operator+=(const Complex& other) {
        real_ += other.real_;
        imag_ += other.imag_;
        return *this;
    }
};

Complex a(1, 2), b(3, 4);
Complex c = a + b;  // Calls a.operator+(b)

Member vs Non-Member Operators

Member operators: Left operand is *this

class Vector {
public:
    Vector operator+(const Vector& rhs) const;  // this + rhs
};

Non-member operators: Both operands are parameters

Vector operator+(const Vector& lhs, const Vector& rhs);

When to use each:

• Member: Unary operators (-, ++, *), compound assignment (+=, *=), subscript ([]), call (()), member access (->)
• Non-member: Symmetric binary operators (+, -, *), stream operators (<<, >>)
• Friend: Non-member needing private access

class Rational {
    int num_, den_;
    friend Rational operator+(const Rational& lhs, const Rational& rhs);
public:
    Rational(int n, int d = 1) : num_(n), den_(d) {}
};

// Non-member allows: 2 + Rational(3,4) via implicit conversion
Rational operator+(const Rational& lhs, const Rational& rhs) {
    return Rational(lhs.num_ * rhs.den_ + rhs.num_ * lhs.den_,
                    lhs.den_ * rhs.den_);
}

Canonical Operator Patterns

Arithmetic Operators

Implement compound assignment (+=), then derive binary operator (+):

class Number {
    int value_;
public:
    Number& operator+=(const Number& rhs) {
        value_ += rhs.value_;
        return *this;
    }
};

// Non-member, defined in terms of +=
Number operator+(Number lhs, const Number& rhs) {
    lhs += rhs;  // lhs is a copy, so modify it
    return lhs;
}

Comparison Operators

C++20 introduced the spaceship operator (<=>), but pre-C++20:

class Point {
    int x_, y_;
public:
    bool operator==(const Point& other) const {
        return x_ == other.x_ && y_ == other.y_;
    }
    
    bool operator!=(const Point& other) const {
        return !(*this == other);  // Implement in terms of ==
    }
    
    bool operator<(const Point& other) const {
        return (x_ < other.x_) || (x_ == other.x_ && y_ < other.y_);
    }
    
    // Define >, <=, >= in terms of < and ==
};

C++20 spaceship simplifies this:

class Point {
    int x_, y_;
public:
    auto operator<=>(const Point&) const = default;  // Generates all comparisons
};

Increment/Decrement

Prefix returns reference; postfix returns copy:

class Counter {
    int count_;
public:
    // Prefix: ++c
    Counter& operator++() {
        ++count_;
        return *this;
    }
    
    // Postfix: c++
    Counter operator++(int) {  // Dummy int parameter
        Counter temp = *this;
        ++(*this);  // Use prefix version
        return temp;
    }
};

Subscript Operator

class Array {
    int* data_;
    size_t size_;
public:
    int& operator[](size_t index) {
        return data_[index];
    }
    
    const int& operator[](size_t index) const {
        return data_[index];
    }
};

C++23 allows multidimensional subscript:

class Matrix {
public:
    double& operator[](size_t row, size_t col);  // C++23
};

Stream Insertion/Extraction

Always non-member to allow std::cout << obj:

class Person {
    std::string name_;
    int age_;
    friend std::ostream& operator<<(std::ostream&, const Person&);
public:
    Person(std::string n, int a) : name_(n), age_(a) {}
};

std::ostream& operator<<(std::ostream& os, const Person& p) {
    return os << p.name_ << " (" << p.age_ << ")";
}

Conversion Operators

Allow implicit or explicit conversion to other types:

class Fraction {
    int num_, den_;
public:
    // Implicit conversion to double
    operator double() const {
        return static_cast<double>(num_) / den_;
    }
    
    // Explicit conversion to bool (C++11)
    explicit operator bool() const {
        return num_ != 0;
    }
};

Fraction f(3, 4);
double d = f;  // Implicit: calls operator double()
// bool b = f;  // Error: explicit conversion required
bool b = static_cast<bool>(f);  // OK
if (f) { }  // OK: contextual conversion to bool

Inheritance: The Is-A Relationship

Inheritance models taxonomic relationships where a derived class “is a” specialized version of a base class. C++ supports single and multiple inheritance with three access modes.

class Shape {
protected:
    std::string color_;
public:
    Shape(std::string c) : color_(c) {}
    virtual double area() const = 0;  // Pure virtual
    virtual ~Shape() = default;
};

class Circle : public Shape {
    double radius_;
public:
    Circle(std::string c, double r) : Shape(c), radius_(r) {}
    
    double area() const override {
        return 3.14159 * radius_ * radius_;
    }
};

Inheritance Access Modes

Public inheritance models “is-a”: Circle is-a Shape. Most common. Protected inheritance models “implemented-in-terms-of” (rare). Private inheritance models “implemented-in-terms-of” (prefer composition).

class Stack : private std::vector<int> {  // Private inheritance
public:
    void push(int x) { push_back(x); }
    int pop() { int x = back(); pop_back(); return x; }
};
// Stack is NOT a std::vector publicly

Virtual Functions and Dynamic Dispatch

Virtual functions enable runtime polymorphism: the called function depends on the dynamic type of the object, not the static type of the pointer/reference.

class Animal {
public:
    virtual void speak() const {
        std::cout << "Some sound\\n";
    }
    virtual ~Animal() = default;
};

class Dog : public Animal {
public:
    void speak() const override {  // override keyword: C++11
        std::cout << "Woof!\\n";
    }
};

void makeNoise(const Animal& a) {
    a.speak();  // Dynamic dispatch
}

Dog d;
makeNoise(d);  // Outputs: Woof!

The Virtual Table Mechanism

Virtual functions are implemented via a virtual table (vtable): a compile-time array of function pointers for each polymorphic class. Each object contains a hidden vptr pointing to its class’s vtable.

Cost: One pointer per object, one indirection per virtual call. This is the “overhead” of polymorphism.

Abstract Classes and Pure Virtual Functions

A pure virtual function has no implementation and is declared with = 0. Classes with pure virtuals are abstract: cannot be instantiated.

class Drawable {
public:
    virtual void draw() const = 0;  // Pure virtual
    virtual ~Drawable() = default;
};

class Rectangle : public Drawable {
public:
    void draw() const override {
        // Implementation
    }
};

// Drawable d;  // Error: cannot instantiate abstract class
Rectangle r;    // OK: Rectangle is concrete

Interface idiom: Abstract class with only pure virtuals and no data members.

The Override and Final Specifiers

C++11 added override and final to catch errors:

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

class Derived : public Base {
public:
    void foo(double x) override;  // Error: doesn't override (different signature)
    void bar() override;          // Error: doesn't override (missing const)
};

final prevents further overriding or derivation:

class Base {
public:
    virtual void method() final;  // Cannot be overridden
};

class Derived final : public Base {  // Cannot be further derived
};

Virtual Destructors: A Critical Rule

If a class has virtual functions, its destructor must be virtual. Otherwise, deleting a derived object through a base pointer causes undefined behavior:

class Base {
public:
    ~Base() { std::cout << "Base destroyed\\n"; }
};

class Derived : public Base {
    int* data_;
public:
    Derived() : data_(new int[100]) {}
    ~Derived() { delete[] data_; }  // CRITICAL: must run
};

Base* p = new Derived;
delete p;  // UB: Only Base destructor runs, memory leak!

Solution: Make base destructor virtual:

class Base {
public:
    virtual ~Base() { }  // Virtual destructor
};

Slicing Problem

Assigning a derived object to a base object slices off the derived parts:

class Base { int x_; };
class Derived : public Base { int y_; };

Derived d;
Base b = d;  // Slicing: y_ is lost

Base& ref = d;  // OK: Reference preserves dynamic type
Base* ptr = &d;  // OK: Pointer preserves dynamic type

Rule: Pass polymorphic types by pointer or reference, never by value.

Templates: Compile-Time Polymorphism

Templates enable writing code that works with any type satisfying certain requirements, with full type checking at compile time and zero runtime overhead. Unlike runtime polymorphism (virtual functions), templates generate specialized code for each type used.

Function Templates

template<typename T>
T max(T a, T b) {
    return (a > b) ? a : b;
}

auto x = max(10, 20);         // T = int
auto y = max(3.14, 2.71);     // T = double
auto z = max<long>(5, 10);    // Explicit T = long

Template Argument Deduction

The compiler deduces template parameters from function arguments. Deduction follows strict rules:

template<typename T>
void process(T value, T* ptr);

int x = 5;
process(x, &x);  // OK: T = int

double d = 3.14;
// process(x, &d);  // Error: T is int or double?

Class Templates

template<typename T>
class Stack {
    std::vector<T> data_;
public:
    void push(const T& value) { data_.push_back(value); }
    
    T pop() {
        T value = data_.back();
        data_.pop_back();
        return value;
    }
    
    bool empty() const { return data_.empty(); }
};

Stack<int> intStack;
Stack<std::string> stringStack;

Member Function Templates

Templates can appear at multiple levels:

template<typename T>
class Container {
public:
    // Member function template
    template<typename U>
    void insert(U&& value) {
        // ...
    }
};

Container<int> c;
c.insert(42);       // U = int
c.insert("hello");  // U = const char*

Template Specialization

Full Specialization

Provide a completely different implementation for a specific type:

template<typename T>
class TypeName {
public:
    static const char* get() { return "unknown"; }
};

template<>
class TypeName<int> {
public:
    static const char* get() { return "int"; }
};

template<>
class TypeName<double> {
public:
    static const char* get() { return "double"; }
};

Partial Specialization (Class Templates Only)

Specialize for a subset of template parameters:

template<typename T, typename U>
class Pair {
    T first_;
    U second_;
};

// Partial specialization: both types the same
template<typename T>
class Pair<T, T> {
    T first_, second_;
public:
    bool equal() const { return first_ == second_; }
};

// Partial specialization: pointer types
template<typename T>
class Pair<T*, T*> {
    // Special implementation for pointers
};

Non-Type Template Parameters

Templates can take compile-time constant values:

template<typename T, size_t N>
class Array {
    T data_[N];
public:
    constexpr size_t size() const { return N; }
    
    T& operator[](size_t i) { return data_[i]; }
    const T& operator[](size_t i) const { return data_[i]; }
};

Array<int, 10> arr1;      // Different type from...
Array<int, 20> arr2;      // ...this

Non-type parameters can be: integers, enums, pointers, references, nullptr_t, and (C++20) floating-point and class types.

Variadic Templates (C++11)

Templates accepting arbitrary numbers of arguments:

template<typename... Args>
void print(Args... args) {
    ((std::cout << args << ' '), ...);  // Fold expression (C++17)
    std::cout << '\\n';
}

print(1, 2.5, "hello", 'x');  // Any number/types of arguments

Parameter Pack Expansion

template<typename... Ts>
class Tuple;  // Declaration

// Recursive inheritance
template<typename T, typename... Ts>
class Tuple<T, Ts...> : public Tuple<Ts...> {
    T value_;
public:
    Tuple(T v, Ts... vs) : Tuple<Ts...>(vs...), value_(v) {}
};

template<>
class Tuple<> {  // Base case
};

SFINAE: Substitution Failure Is Not An Error

When template substitution fails, the candidate is removed from overload set instead of causing error:

template<typename T>
typename T::value_type getValue(T container) {  // Only if T has value_type
    return container[0];
}

template<typename T>
T getValue(T value) {  // Fallback
    return value;
}

std::vector<int> vec{1, 2, 3};
auto x = getValue(vec);  // Calls first overload
auto y = getValue(42);   // Calls second overload (first SFINAE'd out)

Modern C++ uses std::enable_if for SFINAE:

template<typename T>
std::enable_if_t<std::is_integral_v<T>, T>
increment(T value) {
    return value + 1;
}

increment(10);    // OK
// increment(3.14);  // Error: no matching function

C++20 concepts provide cleaner syntax:

template<std::integral T>
T increment(T value) {
    return value + 1;
}

Smart Pointers: Automated Memory Management

Raw pointers require manual memory management with new/delete, leading to leaks, double-deletes, and dangling pointers. Smart pointers from <memory> automate lifetime management through RAII.

unique_ptr: Exclusive Ownership

unique_ptr<T> represents exclusive ownership: exactly one owner, non-copyable but movable. The pointed-to object is destroyed when the unique_ptr is destroyed.

#include <memory>

std::unique_ptr<int> p1(new int(42));
// std::unique_ptr<int> p2 = p1;  // Error: cannot copy

std::unique_ptr<int> p2 = std::move(p1);  // OK: transfer ownership
// p1 is now nullptr

auto p3 = std::make_unique<int>(100);  // Preferred (C++14)

Why make_unique?

// Problematic:
process(std::unique_ptr<T>(new T), might_throw());
// If might_throw() throws after new but before unique_ptr construction, leak!

// Safe:
process(std::make_unique<T>(), might_throw());
// make_unique is atomic: allocation and unique_ptr construction happen together

unique_ptr for Arrays

std::unique_ptr<int[]> arr(new int[10]);
arr[0] = 5;  // Operator[] available for array version

// Prefer std::vector or std::array
std::vector<int> vec(10);  // Better

Custom Deleters

struct FileCloser {
    void operator()(FILE* fp) const {
        if (fp) fclose(fp);
    }
};

std::unique_ptr<FILE, FileCloser> file(fopen("data.txt", "r"));
// File automatically closed when unique_ptr destroyed

shared_ptr: Shared Ownership

shared_ptr<T> uses reference counting: the object is destroyed when the last shared_ptr owning it is destroyed. Copyable and movable.

std::shared_ptr<int> p1 = std::make_shared<int>(42);
std::shared_ptr<int> p2 = p1;  // Both own the object
// Reference count: 2

p1.reset();  // p1 releases ownership, count = 1
// p2 still valid, object alive

Control Block Architecture

Each shared_ptr has two pointers:

1. Pointer to the managed object
2. Pointer to the control block (reference counts, deleter)

// Preferred: single allocation for object + control block
auto p1 = <int>(42);

// Avoid: two allocations
std::shared_ptr<int> p2(new int(42));

Cyclic References Problem

struct Node {
    std::shared_ptr<Node> next;
};

std::shared_ptr<Node> a = std::make_shared<Node>();
std::shared_ptr<Node> b = std::make_shared<Node>();

a->next = b;  // a owns b, count = 2
b->next = a;  // b owns a, count = 2
// Neither can be destroyed: memory leak!

weak_ptr: Breaking Cycles

weak_ptr<T> observes a shared_ptr without affecting reference count. Used to break cycles and check if object still exists.

struct Node {
    std::shared_ptr<Node> next;
    std::weak_ptr<Node> prev;  // Doesn't own
};

std::shared_ptr<Node> a = std::make_shared<Node>();
std::shared_ptr<Node> b = std::make_shared<Node>();

a->next = b;
b->prev = a;  // Weak reference: no cycle

Using weak_ptr

std::shared_ptr<int> sp = std::make_shared<int>(42);
std::weak_ptr<int> wp = sp;

if (auto locked = wp.lock()) {  // Attempt to get shared_ptr
    std::cout << *locked << '\\n';  // Object still exists
} else {
    std::cout << "Object destroyed\\n";
}

Comparison: unique_ptr vs shared_ptr

Rule of Thumb: Default to unique_ptr. Use shared_ptr only when ownership truly must be shared.

Returning Smart Pointers from Functions

// Return unique_ptr when transferring ownership
std::unique_ptr<Widget> createWidget() {
    return std::make_unique<Widget>();
}

auto w = createWidget();  // Ownership transferred via move

// Prefer returning by value for copyable types
Widget createWidget2() {
    return Widget{};  // Copy elision / move
}

Smart Pointers and Polymorphism

class Base { 
public:
    virtual ~Base() = default; 
};
class Derived : public Base {};

std::unique_ptr<Base> p = std::make_unique<Derived>();
// Polymorphism works: Derived destructor called when p destroyed

Common Pitfalls

Constructing shared_ptr from Same Raw Pointer Twice

int* raw = new int(42);
std::shared_ptr<int> p1(raw);
std::shared_ptr<int> p2(raw);  // DISASTER: double-delete!

// Each shared_ptr has independent control block

Never create multiple shared_ptr from the same raw pointer. Use make_shared or copy existing shared_ptr.

Move Semantics: Avoiding Expensive Copies

Before C++11, returning or passing large objects by value meant expensive copies. Move semantics allow transferring resources from temporary objects instead of copying them.

class Buffer {
    char* data_;
    size_t size_;
public:
    // Constructor
    Buffer(size_t s) : data_(new char[s]), size_(s) {}
    
    // Copy constructor (deep copy)
    Buffer(const Buffer& other) : data_(new char[other.size_]), size_(other.size_) {
        std::copy(other.data_, other.data_ + size_, data_);
    }
    
    // Move constructor (transfer ownership)
    Buffer(Buffer&& other) noexcept 
        : data_(other.data_), size_(other.size_) {
        other.data_ = nullptr;
        other.size_ = 0;
    }
    
    ~Buffer() { delete[] data_; }
};

Move Constructor and Move Assignment

Move operations should be noexcept when possible—this enables optimizations in standard containers:

class Widget {
    std::string name_;
    std::vector<int> data_;
public:
    // Move constructor
    Widget(Widget&& other) noexcept
        : name_(std::move(other.name_)),
          data_(std::move(other.data_)) {
    }
    
    // Move assignment
    Widget& operator=(Widget&& other) noexcept {
        if (this != &other) {
            name_ = std::move(other.name_);
            data_ = std::move(other.data_);
        }
        return *this;
    }
};

Note: std::move on member variables is necessary because a named rvalue reference (like other) is itself an lvalue!

std::move: Unconditional Cast to Rvalue

std::move doesn’t move anything—it just casts its argument to an rvalue reference, enabling move semantics:

std::string s1 = "hello";
std::string s2 = std::move(s1);  // s1's data moved to s2
// s1 is now in "valid but unspecified" state

After std::move: The object remains alive and destructible, but its value is unspecified. Only reassign or destroy it.

std::string s = "hello";
std::string t = std::move(s);

// s.clear();  // OK: Reset to known state
// s = "new";  // OK: Reassign
// auto len = s.size();  // DANGEROUS: Value unspecified

Move-Only Types

Some types cannot be copied, only moved: unique_ptr, thread, iostream, etc.

std::unique_ptr<int> p1 = std::make_unique<int>(42);
// std::unique_ptr<int> p2 = p1;  // Error: cannot copy
std::unique_ptr<int> p2 = std::move(p1);  // OK: move

std::vector<std::unique_ptr<int>> vec;
vec.push_back(std::make_unique<int>(10));  // Move into vector

Return Value Optimization (RVO) and NRVO

Compilers can elide copies/moves when returning by value:

Widget createWidget() {
    return Widget{};  // RVO: No move/copy, constructed directly in caller
}

Widget createWidget2() {
    Widget w;
    // ...
    return w;  // NRVO: Named Return Value Optimization (maybe)
}

Don’t std::move return values—it inhibits RVO:

Widget createWidget() {
    Widget w;
    return std::move(w);  // BAD: Prevents NRVO, forces move
}

Perfect Forwarding with std::forward

When writing wrapper functions, you want to forward arguments exactly as received—preserving lvalue/rvalue-ness. This requires forwarding references (a.k.a. universal references).

template<typename T>
void wrapper(T&& arg) {  // Forwarding reference
    target(std::forward<T>(arg));  // Perfect forwarding
}

int x = 10;
wrapper(x);        // T = int&, arg forwarded as lvalue
wrapper(10);       // T = int, arg forwarded as rvalue
wrapper(std::move(x));  // T = int, arg forwarded as rvalue

Forwarding Reference Rules

T&& is a forwarding reference only when:

1. T is a template type parameter
2. Type deduction occurs

template<typename T>
void func(T&& x);  // Forwarding reference

template<typename T>
void func(std::vector<T>&& x);  // NOT forwarding reference (no deduction for &&)

void func(int&& x);  // NOT forwarding reference (not a template)

Variadic Template Forwarding

Combining variadic templates with perfect forwarding:

template<typename T, typename... Args>
std::unique_ptr<T> make_unique(Args&&... args) {
    return std::unique_ptr<T>(new T(std::forward<Args>(args)...));
}

auto p = make_unique<std::pair<int, std::string>>(42, "hello");

When to Use Move vs Forward

• std::move: When you know you have an rvalue or want to treat something as rvalue
• std::forward: In templates, when you want to preserve the value category

template<typename T>
void process(T&& arg) {
    // Use arg multiple times...
    
    target(std::forward<T>(arg));  // Forward on last use
}

Move Semantics and Exception Safety

Move operations should be noexcept when possible. Standard containers use move only if noexcept:

class Widget {
public:
    Widget(Widget&& other) noexcept { /* ... */ }
    Widget& operator=(Widget&& other) noexcept { /* ... */ }
};

std::vector<Widget> vec;
vec.push_back(Widget{});  // Uses move (noexcept)

// If move is not noexcept, vector uses copy (for strong exception guarantee)

Lambda Expressions: Anonymous Functions

C++11 introduced lambdas: inline anonymous function objects with concise syntax. Lambdas are extensively used with algorithms, callbacks, and asynchronous operations.

auto sum = [](int a, int b) { return a + b; };
std::cout << sum(3, 4);  // Outputs: 7

std::vector<int> v = {4, 2, 5, 1, 3};
std::sort(v.begin(), v.end(), [](int a, int b) { return a > b; });
// v is now {5, 4, 3, 2, 1}

Lambda Syntax

[captures](parameters) specifiers -> return_type { body }

• captures: Variables from enclosing scope
• parameters: Function parameters (optional, default ())
• specifiers: mutable, constexpr, noexcept
• return_type: Can be deduced or explicit
• body: Function implementation

Minimal Lambda

auto f = [] { return 42; };  // No parameters, deduced return type

Capture Modes

Lambdas can capture variables from their enclosing scope:

Capture by Value

int x = 10;
auto lambda = [x]() { return x * 2; };  // Captures x by value
x = 20;
std::cout << lambda();  // Outputs: 20 (captured value at lambda creation)

Capture by Reference

int x = 10;
auto lambda = [&x]() { return x * 2; };  // Captures x by reference
x = 20;
std::cout << lambda();  // Outputs: 40 (current value of x)