Summary of Key Points

ref: https://github.com/0voice/cpp-learning-2025

The Practical Advanced Topics section focuses on the core competencies of C++ engineering development, covering four key modules: Design Patterns, Multithreaded Programming, Performance Optimization, and Engineering Practices. It helps developers progress from “knowing the syntax” to “building projects” and solving complex problems in real-world development.

1. Design Patterns

Design patterns are proven solutions to common problems in specific contexts, crystallized from the engineering experience of predecessors. Mastering core design patterns significantly improves code reusability, maintainability, and extensibility, which are essential skills for intermediate and senior C++ development.

1.1 Core Design Principles (SOLID)

All design patterns are built upon five fundamental principles:

  • Single Responsibility Principle (SRP): A class should have only one reason to change, avoiding functional coupling.
  • Open/Closed Principle (OCP): Software entities should be open for extension but closed for modification (extend functionality through abstraction/interfaces, not by modifying existing code).
  • Liskov Substitution Principle (LSP): Objects of a superclass should be replaceable with objects of its subclasses without breaking the program’s correctness (subclasses must be compatible with the superclass interface).
  • Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they do not use. Split bloated interfaces into more specific ones.
  • Dependency Inversion Principle (DIP): Depend upon abstractions (interfaces/base classes), not upon concrete implementations. High-level modules should not depend on low-level modules; both should depend on abstractions.

1.2 High-Frequency C++ Design Patterns in Practice

(1) Singleton Pattern

  • Primary Use Case: Ensure a class has only one instance and provide a global point of access (e.g., configuration manager, logger, database connection pool).
  • Core Requirements: Thread safety, prevention of copying, automatic resource release.
  • Recommended Implementation: C++11 Static Local Variable Version (Simplest and Safest)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
#include <mutex>
#include <iostream>
using namespace std;

class ConfigManager {
private:
    // Private constructor (prevents external instantiation)
    ConfigManager() {
        // Initialization: Load configuration file (simulated)
        cout << "ConfigManager initialized, loading configuration file." << endl;
    }

    // Private destructor (prevents external destruction)
    ~ConfigManager() {
        // Resource cleanup: Save configuration (simulated)
        cout << "ConfigManager destroyed, saving configuration." << endl;
    }

    // Disable copy and move semantics (C++11 and later)
    ConfigManager(const ConfigManager&) = delete;
    ConfigManager& operator=(const ConfigManager&) = delete;
    ConfigManager(ConfigManager&&) = delete;
    ConfigManager& operator=(ConfigManager&&) = delete;

public:
    // Global access point: Static member function
    static ConfigManager& GetInstance() {
        // Since C++11, static local variable initialization is thread-safe
        static ConfigManager instance;
        return instance;
    }

    // Business interface: Get configuration
    string GetConfig(const string& key) {
        // Simulated configuration storage
        if (key == "timeout") return "30s";
        if (key == "max_conn") return "1000";
        return "default";
    }
};

// Test: Accessing the singleton in a multithreaded environment
void ThreadFunc() {
    string timeout = ConfigManager::GetInstance().GetConfig("timeout");
    cout << "Thread " << this_thread::get_id() << " got timeout config: " << timeout << endl;
}

int main() {
    // Single-threaded access
    ConfigManager& config1 = ConfigManager::GetInstance();
    ConfigManager& config2 = ConfigManager::GetInstance();
    cout << "Are config1 and config2 the same instance? " << (&config1 == &config2) << endl; // true

    // Multithreaded access (verify thread safety)
    thread t1(ThreadFunc);
    thread t2(ThreadFunc);
    t1.join();
    t2.join();

    return 0;
}
  • Key Points:
    1. Private constructor/destructor + deleted copy/move functions ensure no external instantiation or copying.
    2. Thread safety for static local variable initialization is guaranteed by the C++11 standard, eliminating the need for manual locks.
    3. The instance’s lifetime matches the program’s, with automatic resource release upon destruction, preventing memory leaks.

(2) Factory Pattern

  • Primary Use Case: Encapsulate object creation logic to decouple object creation from usage (e.g., creating different types of database connections or loggers based on configuration).
  • Categories: Simple Factory (Static Factory), Factory Method, Abstract Factory (increasing complexity).
  • Practical Example: Factory Method Pattern (Supports extensibility, adheres to OCP)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
#include <string>
#include <memory>
#include <iostream>
using namespace std;

// Abstract Product: Logger Interface (depend on abstraction)
class Logger {
public:
    virtual ~Logger() = default; // Virtual destructor ensures proper derived class destruction
    virtual void Log(const string& msg) = 0; // Pure virtual function defines the interface
};

// Concrete Product 1: Console Logger
class ConsoleLogger : public Logger {
public:
    void Log(const string& msg) override {
        cout << "[Console] " << msg << endl;
    }
};

// Concrete Product 2: File Logger
class FileLogger : public Logger {
public:
    void Log(const string& msg) override {
        // Simulate writing to a file
        cout << "[File] " << msg << endl;
    }
};

// Abstract Factory: Logger Factory Interface
class LoggerFactory {
public:
    virtual ~LoggerFactory() = default;
    virtual unique_ptr<Logger> CreateLogger() = 0;
};

// Concrete Factory 1: Console Logger Factory
class ConsoleLoggerFactory : public LoggerFactory {
public:
    unique_ptr<Logger> CreateLogger() override {
        return make_unique<ConsoleLogger>();
    }
};

// Concrete Factory 2: File Logger Factory
class FileLoggerFactory : public LoggerFactory {
public:
    unique_ptr<Logger> CreateLogger() override {
        return make_unique<FileLogger>();
    }
};

// Client Code (depends on abstraction, not concrete implementation)
void ClientCode(LoggerFactory& factory) {
    unique_ptr<Logger> logger = factory.CreateLogger();
    logger->Log("System started successfully");
    logger->Log("Processing user request");
}

int main() {
    // Scenario 1: Use console logging
    ConsoleLoggerFactory consoleFactory;
    ClientCode(consoleFactory);

    // Scenario 2: Switch to file logging (no modification to client code, adhering to OCP)
    FileLoggerFactory fileFactory;
    ClientCode(fileFactory);

    return 0;
}
  • Core Advantages:
    1. To add a new logger type (e.g., network logger), simply add a new concrete product class and a new concrete factory class without modifying the client code.
    2. Decouples object creation from usage, making client code highly flexible by depending only on abstract interfaces.

(3) Observer Pattern

  • Primary Use Case: Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically (e.g., event notification, message subscription).
  • Core Roles: Subject (the observed object), Observer (objects receiving notifications).
  • Practical Example: Event Notification System
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
#include <vector>
#include <memory>
#include <string>
#include <iostream>
#include <algorithm>
#include <mutex>
using namespace std;

// Forward declaration: Subject class needs to know about Observer
class Subject;

// Observer Interface
class Observer {
public:
    virtual ~Observer() = default;
    virtual void Update(Subject* subject, const string& msg) = 0; // Receive notification
};

// Subject Class (the observed object)
class Subject {
private:
    vector<weak_ptr<Observer>> observers_; // Use weak_ptr to avoid circular references
    mutex mtx_; // For thread safety

public:
    // Register an observer
    void Attach(shared_ptr<Observer> observer) {
        lock_guard<mutex> lock(mtx_);
        observers_.emplace_back(observer);
    }

    // Remove an observer
    void Detach(Observer* observer) {
        lock_guard<mutex> lock(mtx_);
        observers_.erase(
            remove_if(observers_.begin(), observers_.end(),
                [observer](const weak_ptr<Observer>& wp) {
                    return wp.expired() || wp.lock().get() == observer;
                }),
            observers_.end()
        );
    }

    // Notify all observers
    void Notify(const string& msg) {
        lock_guard<mutex> lock(mtx_);
        for (auto it = observers_.begin(); it != observers_.end();) {
            if (auto sp = it->lock()) { // Check if observer is still alive
                sp->Update(this, msg);
                ++it;
            } else {
                it = observers_.erase(it); // Clean up destroyed observers
            }
        }
    }
};

// Concrete Subject: Message Center
class MessageCenter : public Subject {
public:
    void SendMessage(const string& msg) {
        cout << "\nMessageCenter sending message: " << msg << endl;
        Notify(msg); // Notify all observers
    }
};

// Concrete Observer 1: Mobile Client
class MobileClient : public Observer {
private:
    string name_;
public:
    MobileClient(const string& name) : name_(name) {}
    void Update(Subject* subject, const string& msg) override {
        cout << "MobileClient[" << name_ << "] received message: " << msg << endl;
    }
};

// Concrete Observer 2: PC Client
class PCClient : public Observer {
private:
    string name_;
public:
    PCClient(const string& name) : name_(name) {}
    void Update(Subject* subject, const string& msg) override {
        cout << "PCClient[" << name_ << "] received message: " << msg << endl;
    }
};

int main() {
    // Create the subject
    MessageCenter msgCenter;

    // Create observers (use shared_ptr for lifetime management)
    auto mobile1 = make_shared<MobileClient>("Xiao Ming's Phone");
    auto mobile2 = make_shared<MobileClient>("Xiao Hong's Phone");
    auto pc1 = make_shared<PCClient>("Xiao Gang's PC");

    // Register observers
    msgCenter.Attach(mobile1);
    msgCenter.Attach(mobile2);
    msgCenter.Attach(pc1);

    // Send message (all observers receive notification)
    msgCenter.SendMessage("Meeting at 3 PM today");

    // Remove an observer
    msgCenter.Detach(mobile2.get());
    msgCenter.SendMessage("Meeting location changed to Conference Room 3");

    return 0;
}
  • Key Points:
    1. The subject stores observers as weak_ptr to avoid circular references caused by shared_ptr, preventing memory leaks.
    2. Supports dynamic registration and removal of observers, adhering to the Open/Closed Principle.
    3. Locks ensure thread safety in multithreaded environments.

(4) Other High-Frequency Patterns

  • Strategy Pattern: Encapsulates interchangeable algorithms, allowing dynamic switching (e.g., sorting algorithms, payment methods).
  • Builder Pattern: Constructs complex objects step-by-step (e.g., complex configuration objects, protocol packets).
  • Adapter Pattern: Converts the interface of a class into another interface expected by the client (e.g., adapting legacy system interfaces to new systems).
  • Decorator Pattern: Dynamically adds responsibilities to an object (e.g., logging decorator, caching decorator).

1.3 Principles for Using Design Patterns

  • Avoid Overuse: Design patterns are solutions, not silver bullets. Avoid over-engineering simple problems.
  • Prioritize Interfaces/Abstraction: Depending on abstraction rather than concrete implementation is the core idea behind design patterns.
  • Leverage Language Features: Use smart pointers in C++ to avoid memory leaks, virtual functions for polymorphism, and lambdas to simplify callbacks, making pattern implementations cleaner.
  • Focus on Engineering Value: The ultimate goal of design patterns is to improve code maintainability and extensibility, not to showcase cleverness.

2. Multithreaded Programming

Multithreading is a core technique for improving program performance (fully utilizing multi-core CPUs), but it introduces challenges like thread safety and synchronization. C++11 introduced the standard thread library (<thread>), providing a unified interface for multithreaded programming, replacing platform-specific APIs like pthreads (Linux) and CreateThread (Windows).

2.1 Thread Basics (std::thread)

(1) Thread Creation and Startup

std::thread is the thread class. When an object is created with a thread function, the thread starts automatically. Key points:

  • Thread functions can be function pointers, function objects, or lambda expressions.
  • A started thread must be joined (join() waits for its completion) or detached (detach() lets it run in the background). Otherwise, std::terminate() is called upon program exit.
  • Arguments are passed by value by default. Use std::ref() to pass by reference.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
#include <thread>
#include <string>
#include <iostream>
using namespace std;

// Thread Function 1: Ordinary function
void ThreadFunc1(int a, string msg) {
    cout << "ThreadFunc1: a=" << a << ", msg=" << msg << endl;
}

// Thread Function 2: Function object
class ThreadObj {
public:
    void operator()(int a) {
        cout << "ThreadObj: a=" << a << endl;
    }
};

int main() {
    // 1. Create thread with ordinary function
    thread t1(ThreadFunc1, 10, "hello");

    // 2. Create thread with function object
    ThreadObj obj;
    thread t2(obj, 20);

    // 3. Create thread with lambda (most common)
    thread t3([](int a, string msg) {
        cout << "lambda thread: a=" << a << ", msg=" << msg << endl;
    }, 30, "world");

    // Wait for threads to finish (must call join() or detach())
    t1.join();
    t2.join();
    t3.join();

    cout << "Main thread ends" << endl;
    return 0;
}

(2) Thread Attributes

  • Thread ID: Get the current thread’s ID with this_thread::get_id().
  • Thread Sleep: Pause a thread with this_thread::sleep_for(duration) (e.g., sleep_for(chrono::seconds(1)) sleeps for 1 second).
  • Thread Swap: Swap thread resources using swap(t1, t2) or t1.swap(t2).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
#include <thread>
#include <chrono>
#include <iostream>
using namespace std;

void SleepFunc() {
    cout << "Thread " << this_thread::get_id() << " starts sleeping." << endl;
    this_thread::sleep_for(chrono::milliseconds(500)); // Sleep for 500ms
    cout << "Thread " << this_thread::get_id() << " finishes sleeping." << endl;
}

int main() {
    thread t(SleepFunc);
    cout << "Thread t ID: " << t.get_id() << endl;
    t.join();
    return 0;
}

2.2 Thread Synchronization and Mutexes

When multiple threads access shared resources, “race conditions” occur, leading to data corruption. The core of thread synchronization is “ensuring atomic operations on shared resources.” C++ provides tools like mutex, lock_guard, and unique_lock.

(1) Mutex (std::mutex)

std::mutex is the most basic mutex lock, providing lock() (acquire lock) and unlock() (release lock) interfaces. Core rules:

  • Only one thread can successfully lock the mutex at a time; other threads block until the lock is released.
  • lock() and unlock() must be paired correctly (to avoid deadlocks or resource leaks).
  • It’s recommended to use lock_guard or unique_lock for automatic lock management (following the RAII principle).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
#include <thread>
#include <mutex>
#include <iostream>
using namespace std;

int g_count = 0; // Shared resource
mutex g_mutex;   // Mutex lock

// Thread function: increment the shared resource
void Increment() {
    for (int i = 0; i < 100000; ++i) {
        // Method 1: Manual lock/unlock (not recommended, easy to forget unlock())
        // g_mutex.lock();
        // ++g_count;
        // g_mutex.unlock();

        // Method 2: lock_guard (RAII, automatic lock/unlock, recommended)
        lock_guard<mutex> lock(g_mutex);
        ++g_count; // Critical section: atomic operation
    }
}

int main() {
    thread t1(Increment);
    thread t2(Increment);

    t1.join();
    t2.join();

    cout << "Final count: " << g_count << endl; // Correctly outputs 200000 (no race condition)
    return 0;
}

(2) unique_lock (Flexible Lock Management)

lock_guard is a simple lock manager (locks on construction, unlocks on destruction). unique_lock is more flexible, supporting:

  • Deferred locking (std::defer_lock).
  • Attempted locking (try_lock()).
  • Timeout-based locking (try_lock_for()).
  • Manual unlocking (unlock()).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#include <thread>
#include <mutex>
#include <chrono>
#include <iostream>
using namespace std;

mutex g_mutex;

void TryLockFunc() {
    unique_lock<mutex> lock(g_mutex, defer_lock); // Defer locking
    if (lock.try_lock_for(chrono::milliseconds(100))) { // Try to lock with a 100ms timeout
        cout << "Thread " << this_thread::get_id() << " successfully acquired lock." << endl;
        this_thread::sleep_for(chrono::milliseconds(200)); // Hold lock for 200ms
        // Automatically unlocks on destruction
    } else {
        cout << "Thread " << this_thread::get_id() << " failed to acquire lock (timeout)." << endl;
    }
}

int main() {
    thread t1(TryLockFunc);
    thread t2(TryLockFunc);

    t1.join();
    t2.join();
    return 0;
}

(3) Condition Variable (std::condition_variable)

Condition variables are used for inter-thread communication, allowing a thread to wait until a condition is met before proceeding (e.g., producer-consumer model). Core interfaces:

  • wait(lock): Releases the lock and blocks the thread until awakened by notify_one() or notify_all().
  • notify_one(): Wakes up one waiting thread.
  • notify_all(): Wakes up all waiting threads.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
#include <thread>
#include <mutex>
#include <condition_variable>
#include <queue>
#include <iostream>
using namespace std;

const int MAX_QUEUE_SIZE = 5;
queue<int> g_queue;       // Shared queue (producers add, consumers remove)
mutex g_mutex;            // Mutex lock
condition_variable g_cv;  // Condition variable

// Producer thread: produces data and adds it to the queue
void Producer() {
    for (int i = 1; i <= 10; ++i) {
        unique_lock<mutex> lock(g_mutex);

        // Wait until the queue is not full (avoid overflow)
        g_cv.wait(lock, []() { return g_queue.size() < MAX_QUEUE_SIZE; });

        // Produce data
        g_queue.push(i);
        cout << "Producer produced: " << i << ", queue size: " << g_queue.size() << endl;

        lock.unlock();
        g_cv.notify_one(); // Wake up one consumer

        this_thread::sleep_for(chrono::milliseconds(100)); // Simulate production time
    }
}

// Consumer thread: retrieves data from the queue for consumption
void Consumer() {
    while (true) {
        unique_lock<mutex> lock(g_mutex);

        // Wait until the queue is not empty (avoid consuming from an empty queue)
        g_cv.wait(lock, []() { return !g_queue.empty(); });

        // Consume data
        int data = g_queue.front();
        g_queue.pop();
        cout << "Consumer consumed: " << data << ", queue size: " << g_queue.size() << endl;

        lock.unlock();
        g_cv.notify_one(); // Wake up one producer

        if (data == 10) break; // Exit after consuming the last data item
        this_thread::sleep_for(chrono::milliseconds(200)); // Simulate consumption time
    }
}

int main() {
    thread producer(Producer);
    thread consumer(Consumer);

    producer.join();
    consumer.join();
    return 0;
}

(4) Atomic Operations (std::atomic)

For simple shared variables (e.g., counters), using atomic is more efficient than mutex (no locking required, operates directly on memory). atomic supports atomic increment, decrement, assignment, etc., and is thread-safe.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#include <thread>
#include <atomic>
#include <iostream>
using namespace std;

atomic<int> g_count = 0; // Atomic variable (thread-safe)

void Increment() {
    for (int i = 0; i < 100000; ++i) {
        ++g_count; // Atomic operation, no lock needed
    }
}

int main() {
    thread t1(Increment);
    thread t2(Increment);

    t1.join();
    t2.join();

    cout << "Final count: " << g_count << endl; // Correctly outputs 200000
    return 0;
}

2.3 Thread Safety and Deadlocks

(1) Core Principles of Thread Safety

  • Minimize Critical Sections: Lock only the operations on shared resources; avoid blocking large sections of code.
  • Avoid Shared Mutable State: Prefer local variables or implement inter-thread communication via message passing rather than shared memory.
  • Prefer Atomic Operations: Use atomic for simple variables and mutex for complex scenarios.
  • Do Not Call External Interfaces Within Critical Sections: External interfaces might lock again, potentially causing deadlocks.

(2) Deadlocks and Prevention

Deadlocks are a nightmare in multithreaded programming, occurring when two or more threads wait indefinitely for each other to release locks. The four necessary conditions for deadlock are:

  1. Mutual Exclusion: A resource can be held by only one thread at a time.
  2. Hold and Wait: A thread holds a lock while waiting for another.
  3. No Preemption: A thread’s locks cannot be forcibly taken away.
  4. Circular Wait: A circular chain of threads exists where each waits for a lock held by the next.

Deadlock Avoidance Strategies:

  • Lock Ordering: All threads acquire multiple locks in a fixed, consistent order (e.g., always lock A before B).
  • Timeout Locking: Use unique_lock::try_lock_for(); release held locks and retry if timeout occurs.
  • Avoid Holding Multiple Locks: Design to use a single lock, or use std::lock() to acquire multiple locks atomically (avoiding partial acquisition).
  • Minimize Lock Holding Time: Complete operations quickly after acquiring a lock and release it promptly.

Deadlock Example (Incorrect):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
mutex mutexA;
mutex mutexB;

// Thread1: locks A then B
void Thread1() {
    mutexA.lock();
    this_thread::sleep_for(chrono::milliseconds(100)); // Give Thread2 time to lock B
    mutexB.lock(); // Deadlock: waits for Thread2 to release B
    // Business logic
    mutexB.unlock();
    mutexA.unlock();
}

// Thread2: locks B then A
void Thread2() {
    mutexB.lock();
    this_thread::sleep_for(chrono::milliseconds(100)); // Give Thread1 time to lock A
    mutexA.lock(); // Deadlock: waits for Thread1 to release A
    // Business logic
    mutexA.unlock();
    mutexB.unlock();
}

Fix (Enforcing Fixed Lock Order):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// Both Thread1 and Thread2 lock in "A then B" order
void Thread1() {
    mutexA.lock();
    mutexB.lock();
    // Business logic
    mutexB.unlock();
    mutexA.unlock();
}

void Thread2() {
    mutexA.lock();
    mutexB.lock();
    // Business logic
    mutexB.unlock();
    mutexA.unlock();
}

2.4 Advanced Multithreading Techniques

(1) Thread Pool

A thread pool is a technique that pre-creates and reuses multiple worker threads to execute tasks, avoiding the overhead of frequent thread creation/destruction (which is expensive). Core components:

  • Task queue: Stores pending tasks.
  • Worker threads: Multiple threads that fetch and execute tasks from the queue in a loop.
  • Management interface: Add tasks, shut down the pool.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
#include <thread>
#include <mutex>
#include <condition_variable>
#include <queue>
#include <functional>
#include <vector>
#include <atomic>
#include <iostream>
using namespace std;

class ThreadPool {
public:
    // Constructor: creates n worker threads
    explicit ThreadPool(size_t thread_num) : stop_(false) {
        for (size_t i = 0; i < thread_num; ++i) {
            workers_.emplace_back([this]() {
                while (true) {
                    function<void()> task;
                    {
                        unique_lock<mutex> lock(mtx_);
                        // Wait for a task or stop signal
                        cv_.wait(lock, [this]() { return stop_ || !tasks_.empty(); });
                        // If stopped and task queue empty, exit thread
                        if (stop_ && tasks_.empty()) return;
                        // Fetch a task
                        task = move(tasks_.front());
                        tasks_.pop();
                    }
                    task(); // Execute the task
                }
            });
        }
    }

    // Destructor: shuts down the thread pool
    ~ThreadPool() {
        {
            unique_lock<mutex> lock(mtx_);
            stop_ = true;
        }
        cv_.notify_all(); // Wake up all worker threads
        for (thread& worker : workers_) {
            worker.join(); // Wait for all threads to finish
        }
    }

    // Add a task (supports any function and arguments)
    template <typename F, typename... Args>
    void AddTask(F&& f, Args&&... args) {
        {
            unique_lock<mutex> lock(mtx_);
            // Prevent adding tasks after shutdown
            if (stop_) throw runtime_error("Cannot add task: thread pool is stopped.");
            // Wrap the task (perfect forwarding)
            tasks_.emplace([=]() {
                forward<F>(f)(forward<Args>(args)...);
            });
        }
        cv_.notify_one(); // Wake up one worker thread
    }

private:
    vector<thread> workers_;       // List of worker threads
    queue<function<void()>> tasks_; // Task queue
    mutex mtx_;                    // Mutex lock
    condition_variable cv_;         // Condition variable
    atomic<bool> stop_;            // Stop flag (atomic for thread safety)
};

// Test task: calculate a + b
int Add(int a, int b) {
    this_thread::sleep_for(chrono::milliseconds(100)); // Simulate task execution time
    return a + b;
}

int main() {
    ThreadPool pool(4); // Create a thread pool with 4 threads

    // Add 10 tasks
    for (int i = 0; i < 10; ++i) {
        pool.AddTask([i]() {
            int result = Add(i, i * 2);
            cout << "Thread " << this_thread::get_id() << " completed task: "
                 << i << " + " << i*2 << " = " << result << endl;
        });
    }

    // Wait for all tasks to complete (simple sleep here; futures could be used in practice)
    this_thread::sleep_for(chrono::seconds(2));

    return 0;
}

(2) std::future and std::promise

future and promise are used for passing data between threads (obtaining return values from asynchronous tasks):

  • promise: The producer thread sets a value.
  • future: The consumer thread retrieves the value (blocks until the value is set).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
#include <thread>
#include <future>
#include <iostream>
using namespace std;

// Producer thread: calculates result and sets it via promise
void Calculate(promise<int> prom) {
    this_thread::sleep_for(chrono::seconds(1));
    int result = 100 + 200;
    prom.set_value(result); // Set the result
}

int main() {
    // Create promise and future
    promise<int> prom;
    future<int> fut = prom.get_future();

    // Start thread, moving the promise (promises are not copyable)
    thread t(Calculate, move(prom));

    // Retrieve the result (blocks until set_value is called)
    cout << "Waiting for calculation result..." << endl;
    int result = fut.get(); // get() can only be called once
    cout << "Calculation result: " << result << endl;

    t.join();
    return 0;
}

(3) std::async (Asynchronous Tasks)

async is a higher-level asynchronous programming interface that automatically creates a thread (or reuses a thread pool) to execute a task and returns a future for retrieving the result. It eliminates manual thread and promise management.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#include <future>
#include <iostream>
using namespace std;

int Calculate() {
    this_thread::sleep_for(chrono::seconds(1));
    return 300 + 400;
}

int main() {
    // Launch an asynchronous task (default: creates a new thread)
    future<int> fut = async(Calculate);

    cout << "Waiting for async task result..." << endl;
    int result = fut.get();
    cout << "Async task result: " << result << endl;

    return 0;
}

3. Performance Optimization

C++'s core strength is “high performance.” Performance optimization is a key competitive edge in C++ development. The core principle is “measure first, optimize later” (use profilers to locate bottlenecks, avoiding premature optimization).

3.1 Code-Level Optimizations

(1) Reduce Copying, Prefer Moving

Copying operations, especially for large objects, consume significant memory and CPU. Move semantics (std::move) introduced in C++11 can eliminate unnecessary copies.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#include <vector>
#include <string>
#include <iostream>
using namespace std;

int main() {
    vector<string> vec;
    string s = "hello world";

    // Method 1: Copy (creates a new string, inefficient)
    vec.push_back(s);
    cout << "Is s empty after copy? " << s.empty() << endl; // false

    // Method 2: Move (transfers ownership, efficient, s becomes empty)
    vec.push_back(move(s));
    cout << "Is s empty after move? " << s.empty() << endl; // true

    return 0;
}
  • Optimization Scenarios:
    1. When a function returns a large object, the return value is automatically moved (with NRVO in C++11 and later).
    2. When adding elements to a container, use move for temporary objects or objects no longer needed.
    3. Implement move constructors and move assignment operators for custom classes (Rule of Five).

(2) Avoid Unnecessary Memory Allocation

Memory allocation (new/malloc) is an expensive operation. Frequent allocations lead to memory fragmentation and performance degradation.

  • Optimization Strategies:
    1. Preallocate memory: Use vector::reserve() to preallocate capacity, avoiding frequent resizing.
    2. Object pools: Reuse objects (e.g., thread pools, connection pools) to reduce creation/destruction overhead.
    3. Prefer stack memory: Use stack memory (local variables) for small objects instead of heap allocation.
    4. Avoid temporary objects: Use emplace_back() instead of push_back() (constructs the object in-place, avoiding a temporary).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
#include <vector>
#include <string>
using namespace std;

struct Person {
    string name;
    int age;
    Person(string n, int a) : name(n), age(a) {}
};

int main() {
    vector<Person> vec;
    vec.reserve(100); // Preallocate capacity for 100 elements, avoiding resizes

    // emplace_back: constructs Person in-place, no temporary object
    vec.emplace_back("Tom", 18);

    // push_back: creates a temporary Person, then copies/moves it into the container
    vec.push_back(Person("Jerry", 17));

    return 0;
}

(3) Loop Optimizations

Loops are common performance hotspots; optimizing them can significantly improve performance:

  • Move invariant calculations outside the loop.
  • Reduce function calls inside loops (function calls have overhead; consider inlining or manual unrolling).
  • Cache-friendly access: Access data in memory order (CPU caches load data in blocks; sequential access has higher cache hit rates).
  • Loop unrolling: Reduces loop control overhead (suitable for loops with a fixed, known iteration count).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// Before optimization: repeated calculation inside loop
for (int i = 0; i < vec.size(); ++i) {
    // vec.size() is called each iteration (vector size is O(1) but still has overhead)
}

// After optimization: move size calculation outside loop
int size = vec.size();
for (int i = 0; i < size; ++i) {
    // ...
}

// Cache-friendly: sequential array access (high CPU cache hit rate)
int arr[1000];
for (int i = 0; i < 1000; ++i) {
    arr[i] = i; // Sequential access, cache-friendly
}

// Not cache-friendly: strided access (low cache hit rate)
for (int i = 0; i < 1000; i += 100) {
    arr[i] = i; // Strided access, frequent cache misses
}

(4) Use Efficient Data Structures and Algorithms

  • Lookup scenarios: unordered_map (average O(1)) is faster than map (O(log n)); use map when ordering is required.
  • Sorting scenarios: sort (quicksort-based) is better than bubble sort or insertion sort.
  • Container selection: Choose based on the operation (e.g., vector for frequent tail insertion/deletion, list for middle insertion/deletion).
  • Avoid inefficient algorithms: For example, nested loops (O(n²)); prefer O(n) or O(n log n) algorithms.

3.2 Compiler Optimizations

Compiler optimizations are “zero-cost” improvements enabled via compiler flags without code changes:

  • GCC/Clang: -O1 (basic), -O2 (commonly used, balances speed and compile time), -O3 (aggressive, may increase binary size).
  • MSVC: /O1 (minimize size), /O2 (maximize speed).

Core compiler optimizations include:

  • Constant folding: Compute constants at compile time (e.g., 3+5 becomes 8).
  • Dead code elimination: Remove code that never executes.
  • Loop optimizations: Unrolling, invariant code motion.
  • Function inlining: Eliminate function call overhead.
  • Instruction reordering: Optimize instruction execution order to better utilize CPU pipelines.

3.3 Memory Optimizations

(1) Reduce Memory Fragmentation

Memory fragmentation occurs from frequent allocation/deallocation of varying-sized heap memory, wasting memory and slowing allocation:

  • Use vector instead of multiple independent new allocations: vector uses contiguous memory, reducing fragmentation.
  • Use memory pools: Preallocate a large block of memory and allocate smaller pieces as needed, returning them to the pool upon deallocation.
  • Align memory: Use alignas to specify memory alignment (CPU accesses aligned memory faster).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// Specify 8-byte memory alignment
struct alignas(8) Data {
    int a;
    char b;
};

// Simplified memory pool example
class MemoryPool {
private:
    char* pool_;
    size_t size_;
    size_t used_;
public:
    MemoryPool(size_t size) : size_(size), used_(0) {
        pool_ = new char[size];
    }
    ~MemoryPool() {
        delete[] pool_;
    }
    void* Allocate(size_t alloc_size) {
        if (used_ + alloc_size > size_) return nullptr;
        void* ptr = pool_ + used_;
        used_ += alloc_size;
        return ptr;
    }
    void Deallocate(void* ptr) {
        // Simplified: doesn't actually free, only resets used_ (suitable for batch deallocation)
        if (ptr == pool_) used_ = 0;
    }
};

(2) Cache Optimization

CPU caches are key to speeding up memory access (caches are 10-100 times faster than RAM). Optimize cache hit rates:

  • Data locality: Place frequently accessed data together (e.g., order struct members by access frequency).
  • Avoid false sharing: Minimize concurrent writes to the same cache line by different threads.
  • Data prefetching: Manually prefetch data into the cache using __builtin_prefetch (GCC) or _mm_prefetch (MSVC).

3.4 Performance Analysis Tools

Identifying bottlenecks is a prerequisite for optimization. Common tools include:

  • GCC/Clang: gprof (simple profiling), perf (Linux system-level profiling).
  • Windows: Visual Studio Performance Profiler.
  • Cross-platform: Valgrind (memory leak detection + profiling), Google Benchmark (microbenchmarking).

Google Benchmark Example (Microbenchmark):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
#include <benchmark/benchmark.h>
#include <vector>

// Benchmark vector::push_back vs emplace_back
static void BM_VectorPushBack(benchmark::State& state) {
    std::vector<int> vec;
    vec.reserve(state.range(0));
    for (auto _ : state) {
        vec.push_back(10);
    }
}
BENCHMARK(BM_VectorPushBack)->Range(8, 8<<10);

static void BM_VectorEmplaceBack(benchmark::State& state) {
    std::vector<int> vec;
    vec.reserve(state.range(0));
    for (auto _ : state) {
        vec.emplace_back(10);
    }
}
BENCHMARK(BM_VectorEmplaceBack)->Range(8, 8<<10);

BENCHMARK_MAIN();

4. Engineering Practices and Standards

The core of engineering development is making code maintainable, collaborative, and extensible, encompassing coding standards, version control, build systems, testing, and more.

4.1 Coding Standards

Coding standards are the foundation of team collaboration. A unified style reduces communication overhead and improves code readability. It is recommended to follow:

  • Google C++ Style Guide: The most popular standard, covering naming, formatting, comments, feature usage, etc.
  • ISO C++ Core Guidelines: Recommended by the C++ standards committee, focusing on safety, efficiency, and maintainability.

Key Standard Points

  • Naming:
    • Classes/Structs/Enums: PascalCase (PersonInfo, LogLevel).
    • Functions/Variables: camelCase (calculateSum, userName) or snake_case (calculate_sum, user_name).
    • Constants/Macros: UPPER_SNAKE_CASE (MAX_QUEUE_SIZE, LOG_DEBUG).
    • Private Members: Suffix with underscore (name_, age_).
  • Formatting:
    • Indentation: 4 spaces (avoid tabs for consistency across editors).
    • Line length: 80-120 characters maximum.
    • Braces: Opening brace for functions/classes on a new line; for loops/conditionals, opening brace follows the statement.
  • Comments:
    • Classes/Functions: Use Doxygen-style comments (describe purpose, parameters, return values, exceptions).
    • Complex logic: Add inline comments explaining the design rationale.
    • Avoid redundant comments (e.g., “i++: increment i”).
  • Feature Usage:
    • Avoid raw new/delete; use smart pointers.
    • Avoid macros; use constexpr or inline functions.
    • Prefer the standard library; avoid reinventing the wheel.
    • Avoid void* and raw arrays; use std::any and std::vector.

4.2 Build Systems

Build systems manage compilation, linking, and dependencies, replacing error-prone manual Makefiles. Common C++ build systems:

CMake is a “meta-build system” that defines build rules in CMakeLists.txt files, generating Makefiles (Linux), Visual Studio solutions (Windows), etc.

Simple CMakeLists.txt Example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# Minimum required CMake version
cmake_minimum_required(VERSION 3.10)

# Project name and version
project(MyProject VERSION 1.0 LANGUAGES CXX)

# Set C++ standard (C++11 and later)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

# Find dependency libraries (e.g., Boost, OpenCV)
# find_package(Boost REQUIRED COMPONENTS system thread)

# Add executable (list source files)
add_executable(MyApp
    src/main.cpp
    src/logger.cpp
    src/config.cpp
)

# Add include directories
target_include_directories(MyApp PUBLIC
    ${PROJECT_SOURCE_DIR}/include
)

# Link dependency libraries
# target_link_libraries(MyApp PUBLIC Boost::system Boost::thread)

# Compiler options (e.g., optimization level, warnings)
if(CMAKE_BUILD_TYPE STREQUAL "Release")
    target_compile_options(MyApp PRIVATE -O2 -Wall -Wextra)
else()
    target_compile_options(MyApp PRIVATE -g -Wall -Wextra)
endif()

Build Commands:

1
2
3
4
5
6
7
8
# Create build directory (out-of-source build, avoid polluting source)
mkdir build && cd build

# Generate Makefile
cmake .. -DCMAKE_BUILD_TYPE=Release

# Compile
make -j4 # -j4 for 4-threaded compilation

(2) Other Build Systems

  • Meson: Simpler than CMake, with a more modern syntax; cross-platform.
  • Bazel: Developed by Google, supports multiple languages, incremental builds; suitable for large projects.
  • Makefile: Suitable for small Linux projects; simple and direct but poor cross-platform support.

4.3 Testing

Testing is central to ensuring code quality. Common C++ testing frameworks include:

(1) Google Test (GTest): Unit Testing

GTest is the most popular C++ unit testing framework, supporting assertions, test suites, parameterized tests, etc.

Testing Example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#include <gtest/gtest.h>
#include "calculator.h" // Header of the code under test

// Test the Add function
TEST(CalculatorTest, Add) {
    Calculator calc;
    EXPECT_EQ(calc.Add(1, 2), 3); // Expect 3, continues if fails
    ASSERT_EQ(calc.Add(-1, -1), -2); // Expect -2, aborts test if fails
    EXPECT_GT(calc.Add(5, 3), 7); // Expect result greater than 7
}

// Test the Subtract function
TEST(CalculatorTest, Subtract) {
    Calculator calc;
    EXPECT_EQ(calc.Subtract(5, 3), 2);
}

int main(int argc, char **argv) {
    testing::InitGoogleTest(&argc, argv);
    return RUN_ALL_TESTS();
}

Integrating GTest with CMake:

1
2
3
4
5
6
7
8
9
10
11
12
# Find GTest
find_package(GTest REQUIRED)
include_directories(${GTEST_INCLUDE_DIRS})

# Add test executable
add_executable(MyTest test/calculator_test.cpp src/calculator.cpp)

# Link GTest
target_link_libraries(MyTest ${GTEST_LIBRARIES} pthread)

# Add test target (run via make test)
add_test(NAME MyTest COMMAND MyTest)

(2) Google Mock (GMock): Mocking

GMock is used to mock dependency objects (e.g., databases, network interfaces), enabling unit tests to run without external resources.

(3) Testing Principles

  • Unit Testing: Test the smallest units (functions/classes) in isolation from dependencies.
  • Cover Core Scenarios: Test both happy paths and edge cases (e.g., invalid arguments, insufficient resources).
  • Automation: Integrate testing into the build pipeline (e.g., CI/CD), running tests automatically on each commit.
  • Fast Feedback: Unit tests should execute quickly (milliseconds), allowing frequent runs.

4.4 Other Engineering Practices

  • Version Control: Use Git for code management, following branch models like Git Flow or GitHub Flow.
  • Code Review: Conduct reviews via Pull Requests (GitHub) or Merge Requests (GitLab) to catch errors early.
  • CI/CD: Use tools like Jenkins or GitHub Actions for continuous integration (automated build, test) and continuous deployment (automated release).
  • Documentation: Maintain API documentation (auto-generated with Doxygen), architecture documents, and user manuals.
  • Error Handling: Use unified error codes or exception types for easier debugging.
  • Logging: Standardize log output (levels: DEBUG/INFO/WARN/ERROR/FATAL) with timestamps, thread IDs, and error descriptions.

The key to improvement is combining theory with practice. The following projects are recommended (from simple to complex):

  1. Logging System: Implement a multi-level, multi-output (console/file) thread-safe logger (using Singleton, multithreading, file I/O).
  2. Thread Pool: Implement a thread pool with task queue, thread reuse, and timeout handling (using multithreading, synchronization).
  3. HTTP Server: Build a simple HTTP server based on TCP, supporting static file serving and routing (using network programming, multithreading).
  4. Database Connection Pool: Implement a connection pool supporting connection reuse, timeout reclamation, and concurrency safety (using Singleton, thread pool, database APIs).
  5. Simplified STL: Implement core components like vector, string, shared_ptr (deepens understanding of STL internals).

Summary

The Practical Advanced Topics section covers the core competencies of C++ engineering development: Design Patterns (code design), Multithreaded Programming (performance enhancement), Performance Optimization (peak efficiency), and Engineering Standards (team collaboration), forming a comprehensive technical framework. The key to learning is “theory + practice”:

  • Understand the core ideas behind design patterns rather than memorizing them.
  • Focus on thread safety in multithreaded programming, avoiding deadlocks and race conditions.
  • Profile before optimizing performance, prioritizing bottleneck resolution.
  • Engineering standards are the foundation of team collaboration; cultivate good coding habits.

By applying this knowledge through practical projects, you can truly evolve from a “C++ beginner” to an “engineering-ready developer.”

说些什么吧！

giscus