实战：利用智能指针重构旧的 C 风格代码，让程序更健壮

各位同仁，各位技术爱好者，大家好！

今天，我们齐聚一堂，共同探讨一个在软件开发领域，尤其是在维护大型、历史悠久的代码库时，经常会遇到的核心问题：如何让我们的程序更加健壮、更不容易出错，尤其是在资源管理方面。我们将聚焦于一个具体而强大的现代C++工具——智能指针，并将其作为重构旧的C风格代码的利器。

在软件工程实践中，我们常常会面对这样的场景：一个庞大的系统，它可能诞生于C语言盛行的年代，或是C++早期版本，其中充斥着大量的裸指针、手动内存分配与释放。这样的代码在功能上或许久经考验，但其脆弱性也显而易见：内存泄漏、野指针、重复释放、异常安全问题，这些都如同潜伏的地雷，随时可能引爆，导致程序崩溃或数据损坏。

作为编程专家，我们的目标不仅是实现功能，更要构建稳定、可靠、易于维护的系统。而智能指针正是C++为我们提供的，解决C风格资源管理困境的优雅方案。它将资源（特别是堆内存）的生命周期管理自动化，遵循“资源获取即初始化”（RAII）原则，极大地提升了代码的健壮性和安全性。

本次讲座，我将带领大家深入理解智能指针的机制，剖析旧代码中的常见问题，并手把手地演示如何利用std::unique_ptr、std::shared_ptr和std::weak_ptr，一步步地重构这些脆弱的代码，使其焕发新生，变得更加坚不可摧。这不是一场空泛的理论探讨，而是基于实战经验的分享，旨在为您提供一套切实可行的重构策略和最佳实践。

第一部分：C风格资源管理的深渊与痛点

在现代C++出现之前，或者在那些仍停留在C风格编程范式的代码库中，资源管理是程序员肩上沉重且易错的负担。最常见的资源就是堆内存，通过malloc/free或new/delete进行分配和释放。然而，这种手动管理方式，尽管提供了极致的控制力，却也带来了无尽的麻烦。

1.1 常见的C风格内存管理陷阱

让我们通过一个简单的C++（但风格偏C）的例子来回顾一下这些问题：

#include <iostream>
#include <cstring> // For strlen, strcpy

// 假设这是一个旧的日志消息结构体
struct LogMessage {
    char* content;
    int level;

    LogMessage(const char* msg, int lvl) : level(lvl) {
        if (msg) {
            content = new char[strlen(msg) + 1];
            strcpy(content, msg);
        } else {
            content = nullptr;
        }
        std::cout << "LogMessage created." << std::endl;
    }

    // 忘记析构函数，或者析构函数不完善，是常见问题
    // ~LogMessage() {
    //     delete[] content; // 如果没有这一行，就会内存泄漏
    //     std::cout << "LogMessage destroyed." << std::endl;
    // }
};

// 一个处理日志的函数
void processLog(LogMessage* msg) {
    if (!msg) return;

    if (msg->level > 5) {
        std::cout << "High priority log: " << (msg->content ? msg->content : "N/A") << std::endl;
        // 假设这里可能抛出异常，例如文件写入失败
        // throw std::runtime_error("Failed to write to log file!");
    } else {
        std::cout << "Normal log: " << (msg->content ? msg->content : "N/A") << std::endl;
    }
}

// 一个工厂函数，返回一个动态分配的LogMessage
LogMessage* createAndGetLogMessage(const char* text, int severity) {
    LogMessage* msg = new LogMessage(text, severity);
    return msg;
}

int main() {
    // 问题1：忘记释放内存
    LogMessage* log1 = new LogMessage("This is an important event.", 8);
    // processLog(log1);
    // ... 很多其他操作 ...
    // delete log1; // 如果忘记这一行，log1的内存和content的内存都会泄漏

    // 问题2：异常安全问题
    LogMessage* log2 = nullptr;
    try {
        log2 = createAndGetLogMessage("Another event.", 3);
        processLog(log2);
        // 如果 processLog 抛出异常，log2 和其内部的 content 内存将不会被释放
        // delete log2; // 这行代码将无法执行
    } catch (const std::exception& e) {
        std::cerr << "Error: " << e.what() << std::endl;
        // 此时 log2 仍然未被释放
    }

    // 问题3：双重释放
    LogMessage* log3 = new LogMessage("Temporary log.", 1);
    delete log3;
    // delete log3; // 再次释放一个已经释放的指针，导致未定义行为，通常是程序崩溃

    // 问题4：悬空指针
    LogMessage* log4 = new LogMessage("Dangling pointer example.", 2);
    LogMessage* ptr_to_log4 = log4;
    delete log4;
    // std::cout << ptr_to_log4->level << std::endl; // 使用已释放的内存，未定义行为

    // 问题5：`new` 与 `delete[]` 不匹配，或 `malloc` 与 `delete` 不匹配
    char* buffer = new char[100];
    // delete buffer; // 应该是 delete[] buffer; 否则可能导致部分内存泄漏或堆损坏

    std::cout << "Program finished." << std::endl;

    return 0;
}

这段看似简单的代码，却包含了手动内存管理中最常见的几种致命缺陷：

• 内存泄漏 (Memory Leak)：最常见的问题。当动态分配的内存不再被使用，但却没有被释放时，就会发生内存泄漏。长时间运行的程序会耗尽系统内存。在上面的例子中，log1 如果忘记 delete，其内存及内部 content 的内存就会泄漏。LogMessage 结构体如果缺少析构函数，也会导致其内部 content 泄漏。
• 异常安全问题 (Exception Safety)：当代码在执行过程中抛出异常时，如果资源释放逻辑位于异常点之后，那么资源将永远无法被释放。log2 的例子完美说明了这一点。
• 双重释放 (Double Free)：对同一块内存区域进行两次释放操作。这会导致未定义行为，通常是程序崩溃，或者更隐蔽的堆损坏，难以调试。log3 的例子。
• 悬空指针 (Dangling Pointer)：当一块内存被释放后，指向它的指针仍然保留其旧的值。此时如果通过该指针访问内存，就会导致未定义行为，可能读到垃圾数据，也可能写入到已被系统回收或重新分配给其他用途的内存区域，引发严重错误。log4 的例子。
• new/delete 不匹配或 malloc/free 不匹配：new 出来的单个对象应该用 delete 释放，new[] 出来的数组应该用 delete[] 释放。同样，malloc 出来的内存用 free 释放。混用或不匹配会导致未定义行为。

这些问题不仅难以在编译时发现，而且在运行时也往往以间歇性崩溃或难以追踪的错误形式出现，给调试和维护带来巨大挑战。

1.2 RAII原则：现代C++的基石

为了解决上述问题，C++引入了“资源获取即初始化”（Resource Acquisition Is Initialization, RAII）这一核心编程原则。RAII 的核心思想是：

1. 将资源的生命周期绑定到一个对象的生命周期上。
2. 当对象创建时，获取资源。
3. 当对象销毁时（无论是正常退出作用域，还是因异常而栈回溯），自动释放资源。

通过将资源封装在类的构造函数和析构函数中，我们确保了资源在任何情况下都能被正确管理。智能指针就是RAII原则在堆内存管理上的典型应用。

第二部分：智能指针——现代C++的资源管理利器

智能指针是C++标准库提供的一种类型，它行为类似于普通指针，但提供了自动化的内存管理功能，遵循RAII原则。它们本质上是封装了裸指针的类模板，在对象被销毁时，会自动调用裸指针的析构函数来释放其指向的内存。

C++11及更高版本提供了三种主要的智能指针：std::unique_ptr、std::shared_ptr 和 std::weak_ptr。std::auto_ptr 已被废弃，我们不会在实战中推荐使用它。

2.1 std::unique_ptr：独占所有权

std::unique_ptr 是一种独占所有权的智能指针。这意味着在任何时间点，只有一个 unique_ptr 可以指向给定的资源。当 unique_ptr 被销毁时，它所指向的资源也会被自动释放。

• 特点：

  • 独占所有权：不能被复制，只能被移动。这意味着资源的所有权可以在 unique_ptr 之间转移，但不会有多个 unique_ptr 同时拥有同一资源。
  • 轻量级：通常与裸指针大小相同，没有额外的开销（除了可能的自定义删除器）。
  • 高效：由于其独占性，不需要像 shared_ptr 那样维护引用计数，因此性能开销极低。
  • 自定义删除器：可以指定一个自定义的删除器，用于管理非堆内存资源（如文件句柄、网络套接字等）。

• 典型使用场景：

  • 局部变量：当一个函数内部需要动态分配内存，并在函数结束时自动释放时。
  • 类成员：当一个类需要独占地拥有一个动态分配的对象时。
  • 工厂函数返回值：当一个工厂函数创建并返回一个新对象的所有权时。

• 创建方式：

  • std::unique_ptr<T> ptr(new T(...)); (不推荐，如果 new T(...) 抛出异常，可能导致内存泄漏)
  • 推荐： std::unique_ptr<T> ptr = std::make_unique<T>(args...); (C++14及以上)
  • 对于数组：std::unique_ptr<T[]> arr = std::make_unique<T[]>(size);

2.2 std::shared_ptr：共享所有权

std::shared_ptr 是一种共享所有权的智能指针。多个 shared_ptr 可以共同拥有同一个资源。它通过引用计数（reference count）来跟踪有多少个 shared_ptr 实例指向同一个资源。当最后一个 shared_ptr 被销毁时，引用计数变为零，资源才会被释放。

• 特点：

  • 共享所有权：可以被复制，所有复制的 shared_ptr 实例都指向同一个资源。
  • 引用计数：内部维护一个引用计数，用于确定何时释放资源。
  • 性能开销：由于需要维护引用计数（通常存储在堆上），其大小是裸指针的两倍，且操作（如复制、赋值）会涉及到引用计数的原子性增减，因此相比 unique_ptr 有一定的性能开销。
  • 自定义删除器：同样支持自定义删除器。

• 典型使用场景：

  • 资源管理器：当多个客户端对象需要访问并共享同一个资源时。
  • 缓存：缓存中的对象可能被多个部分引用。
  • 对象图：当对象的生命周期复杂，难以确定单一所有者时。

• 创建方式：

  • std::shared_ptr<T> ptr(new T(...)); (不推荐，可能导致两次堆内存分配，一次是 T 对象，一次是引用计数块)
  • 推荐： std::shared_ptr<T> ptr = std::make_shared<T>(args...); (更高效，一次堆内存分配)

2.3 std::weak_ptr：非拥有观察者

std::weak_ptr 是一种非拥有（non-owning）的智能指针。它不参与资源的引用计数，因此它的存在不会阻止资源被释放。weak_ptr 主要用于解决 shared_ptr 之间的循环引用问题。

• 特点：

  • 非拥有：不增加资源的引用计数。
  • 观察者：它只是一个观察者，可以检查它所指向的资源是否仍然有效。
  • 安全性：在使用 weak_ptr 访问资源之前，必须先将其转换为 shared_ptr。如果资源已经被释放，转换会失败（返回空的 shared_ptr），从而避免了悬空指针问题。

• 典型使用场景：

  • 解决 shared_ptr 循环引用：当两个或多个对象相互持有对方的 shared_ptr 时，会形成循环引用，导致引用计数永远不会降为零，从而造成内存泄漏。通过将其中一个引用改为 weak_ptr 即可打破循环。
  • 缓存管理：缓存中的对象可能被 shared_ptr 拥有，但缓存本身可以用 weak_ptr 来引用这些对象，以便在对象不再被其他地方引用时，可以被自动清除。
  • 父子关系：子对象持有父对象的 shared_ptr，父对象持有子对象的 weak_ptr。

• 创建方式：

  • std::weak_ptr<T> w_ptr = s_ptr; (从 shared_ptr 创建)
  • std::shared_ptr<T> s_ptr_from_weak = w_ptr.lock(); (获取 shared_ptr，如果资源有效)

2.4 智能指针选择指南

特性/指针类型	std::unique_ptr	std::shared_ptr	std::weak_ptr
所有权	独占所有权，不能复制，只能移动	共享所有权，可复制，通过引用计数管理资源生命周期	非拥有观察者，不影响资源生命周期
开销	极低，通常与裸指针大小相同（无自定义删除器时）	较高，通常是裸指针两倍大小，涉及引用计数原子操作	较高，通常是裸指针两倍大小，与shared_ptr关联
创建	std::make_unique (推荐)	std::make_shared (推荐)	从 shared_ptr 创建
用途	独占资源，工厂函数返回值，类成员，局部动态对象	多个对象共享同一资源，生命周期复杂难以确定所有者	打破 shared_ptr 循环引用，观察者模式，缓存管理
安全性	自动释放资源，避免内存泄漏，异常安全	自动释放资源，避免内存泄漏，异常安全	避免悬空指针 (需先 lock() 获得 shared_ptr)
默认	首选：尽可能使用 unique_ptr，除非确实需要共享所有权	只有在明确需要共享所有权时才使用	仅用于解决 shared_ptr 循环引用或作为非拥有观察者

第三部分：实战重构：从C风格到智能指针

重构旧的C风格代码需要策略和耐心。我们不能指望一步到位，而是应该采取渐进式的方法，小步快跑，每一步都进行测试以确保没有引入新的问题。

3.1 重构策略概述

1. 识别目标： 找出代码中所有使用裸指针进行动态内存管理的地方 (new/delete、malloc/free)。
2. 局部化所有权： 首先在最小的作用域内替换裸指针。如果一个函数创建了一个对象并在函数结束时删除它，这是最容易替换为 unique_ptr 的。
3. 确定所有权语义： 对于每个裸指针，思考其所有权归属。是独占（unique_ptr）？是共享（shared_ptr）？还是只是观察（raw pointer 或 weak_ptr）？
4. 修改函数签名： 当所有权跨越函数边界时，修改函数参数和返回值类型以使用智能指针。
5. 处理非内存资源： 对于文件句柄、网络连接等非内存资源，使用 unique_ptr 或 shared_ptr 的自定义删除器。
6. 逐步迭代和测试： 每完成一小部分重构，都应该编译并运行现有测试（如果存在的话）。如果没有测试，则需要编写单元测试来验证重构的正确性。

3.2 详细重构步骤与示例

我们将以一个更贴近实际的“遗留文档处理器”为例，逐步展示重构过程。

3.2.1 原始C风格代码示例：遗留文档处理器

考虑以下一个模拟的文档处理器，它用C风格的C++编写：

#include <iostream>
#include <string>
#include <vector>
#include <cstdio> // For FILE*

// 假设的文档配置结构体
struct DocConfig {
    char* author;
    int version;
    bool is_encrypted;

    DocConfig(const char* auth, int ver, bool encrypted)
        : version(ver), is_encrypted(encrypted) {
        if (auth) {
            author = new char[strlen(auth) + 1];
            strcpy(author, auth);
        } else {
            author = nullptr;
        }
        std::cout << "DocConfig created for author: " << (author ? author : "N/A") << std::endl;
    }

    // 忘记析构函数，或者复制构造函数、赋值运算符
    ~DocConfig() {
        delete[] author; // 如果忘记，这里就是内存泄漏
        std::cout << "DocConfig destroyed for author: " << (author ? author : "N/A") << std::endl;
    }

    // 复制构造函数和赋值运算符也必须手动实现，否则会浅拷贝导致双重释放
    DocConfig(const DocConfig& other) : version(other.version), is_encrypted(other.is_encrypted) {
        if (other.author) {
            author = new char[strlen(other.author) + 1];
            strcpy(author, other.author);
        } else {
            author = nullptr;
        }
        std::cout << "DocConfig copied for author: " << (author ? author : "N/A") << std::endl;
    }

    DocConfig& operator=(const DocConfig& other) {
        if (this == &other) return *this;
        delete[] author; // 释放旧资源
        if (other.author) {
            author = new char[strlen(other.author) + 1];
            strcpy(author, other.author);
        } else {
            author = nullptr;
        }
        version = other.version;
        is_encrypted = other.is_encrypted;
        std::cout << "DocConfig assigned for author: " << (author ? author : "N/A") << std::endl;
        return *this;
    }
};

// 假设的文档处理器类
class DocumentProcessor {
private:
    char* doc_content; // 存储文档内容的缓冲区
    size_t content_size;
    DocConfig* config; // 指向文档配置的裸指针
    FILE* log_file;    // C风格文件句柄

public:
    DocumentProcessor(size_t size, DocConfig* cfg, const char* log_filename)
        : content_size(size), config(cfg), doc_content(nullptr), log_file(nullptr) {
        doc_content = new char[size];
        memset(doc_content, 0, size); // 初始化为0

        if (log_filename) {
            log_file = fopen(log_filename, "a"); // "a" for append mode
            if (!log_file) {
                std::cerr << "Failed to open log file: " << log_filename << std::endl;
                // 此时 doc_content 已经分配，但如果这里抛出异常，doc_content 就泄漏了
                // throw std::runtime_error("Log file error!");
            }
        }
        std::cout << "DocumentProcessor created with content size " << size << std::endl;
    }

    ~DocumentProcessor() {
        delete[] doc_content; // 释放文档内容
        delete config;        // 释放配置
        if (log_file) {
            fclose(log_file); // 关闭文件句柄
        }
        std::cout << "DocumentProcessor destroyed." << std::endl;
    }

    void processData(const char* data, size_t len) {
        if (len >= content_size) {
            std::cerr << "Data too large for buffer!" << std::endl;
            return;
        }
        strcpy(doc_content, data);
        if (config->is_encrypted) {
            std::cout << "Encrypting data..." << std::endl;
            // 假设这里是加密逻辑
        }
        if (log_file) {
            fprintf(log_file, "Processed by %s (v%d): %sn", config->author, config->version, data);
            fflush(log_file);
        }
        std::cout << "Data processed: " << doc_content << std::endl;
    }

    // 允许获取配置的裸指针，但没有明确所有权语义
    DocConfig* getConfig() const {
        return config;
    }

    // 假设一个工厂函数
    DocumentProcessor* createDefaultProcessor(size_t size, const char* log_path) {
        DocConfig* default_cfg = new DocConfig("Default Author", 1, false);
        return new DocumentProcessor(size, default_cfg, log_path);
    }
};

void run_legacy_system() {
    std::cout << "n--- Running Legacy System ---" << std::endl;
    DocConfig* my_config = new DocConfig("Alice", 2, true);
    DocumentProcessor* processor = nullptr;
    try {
        processor = new DocumentProcessor(256, my_config, "app_log.txt"); // my_config 的所有权转移给了 processor

        processor->processData("Hello World Document.", 100);

        // 如果这里抛出异常，my_config 和 processor 的内存都将泄漏
        // throw std::runtime_error("Processing failed!");

        // 问题：如果外部仍然持有 my_config 指针，但在 processor 析构后使用，将是悬空指针
        // delete my_config; // 错误！processor 会再次删除
        // delete processor; // 应该手动释放
    } catch (const std::exception& e) {
        std::cerr << "Legacy system error: " << e.what() << std::endl;
        // 如果异常发生在 new DocumentProcessor 之后，delete processor; 需要在这里
        // 但如果 new DocumentProcessor 失败，processor 是 nullptr，也不能 delete
        // 且 my_config 在这里可能也无法释放，如果它已经被 DocumentProcessor 拥有。
    }
    // 确保在 main 函数结束前释放所有资源
    delete processor; // 如果 processor 是 nullptr，这个操作是安全的
    // 此时 my_config 已经被 processor 释放，如果再次 delete my_config 会双重释放
    std::cout << "--- Legacy System Finished ---n" << std::endl;
}

int main() {
    run_legacy_system();
    // 思考：如果 run_legacy_system 内部发生异常，资源是否能正确释放？
    // 答案是：不能，存在严重内存泄漏和资源泄漏风险。

    // 另一个问题：如果 DocumentProcessor 的构造函数中打开 log_file 失败并抛出异常
    // new DocConfig 成功，new char[size] 成功，但 new DocumentProcessor 失败
    // 此时 DocConfig 和 char[] 的内存都泄漏了。

    return 0;
}

问题分析：

1. DocConfig 类：

   • 内部 char* author 需要手动 new[]/delete[]。
   • 缺少默认构造函数、移动构造函数和移动赋值运算符。
   • 虽然实现了复制构造函数和复制赋值运算符（通常称为“大三法则”或“大五法则”），但仍需手动维护，容易出错。

2. DocumentProcessor 类：

   • char* doc_content：手动管理动态分配的缓冲区。
   • DocConfig* config：在构造函数中接收裸指针，并在析构函数中 delete。这表明 DocumentProcessor 拥有 DocConfig 对象。但在 main 函数中，my_config 先被 new 出来，然后其裸指针被传递给 DocumentProcessor。这导致了所有权转移的歧义：外部 main 函数不再拥有 my_config，但其指针仍然存在，容易被误用导致双重释放或悬空指针。
   • FILE* log_file：C风格的文件句柄，需要手动 fopen/fclose。如果构造函数中 fopen 失败，在抛出异常时，之前分配的 doc_content 和 config 可能不会被释放，造成内存泄漏。
   • 工厂函数 createDefaultProcessor 返回裸指针，调用者必须手动 delete。
   • getConfig() 返回裸指针，使得外部代码可以修改内部配置，且无法判断 DocConfig 对象的生命周期。

3. run_legacy_system 函数：

   • 完全依赖手动 delete，在异常发生时极易泄漏。
   • my_config 的所有权转移不明确，可能导致外部对已释放内存的访问。

3.2.2 逐步重构：引入智能指针

我们将按照前面提到的策略，一步步地重构上述代码。

*第一步：重构 DocConfig 内部的 `char author`**

DocConfig 内部的 char* author 是独占的，可以被 std::unique_ptr<char[]> 替换。这会使得 DocConfig 自动处理 author 的内存，无需手动实现析构函数、复制构造函数和赋值运算符（至少对于 author 部分）。

#include <iostream>
#include <string>
#include <vector>
#include <cstdio>
#include <memory> // 引入智能指针头文件
#include <cstring> // For strcpy

// 假设的文档配置结构体
struct DocConfig {
    std::unique_ptr<char[]> author; // 改用 unique_ptr 管理 char[]
    int version;
    bool is_encrypted;

    // 构造函数
    DocConfig(const char* auth, int ver, bool encrypted)
        : version(ver), is_encrypted(encrypted) {
        if (auth) {
            size_t len = strlen(auth);
            author = std::make_unique<char[]>(len + 1); // 使用 make_unique
            strcpy(author.get(), auth); // 使用 get() 获取裸指针
        } else {
            author = nullptr;
        }
        std::cout << "DocConfig created for author: " << (author ? author.get() : "N/A") << std::endl;
    }

    // 复制构造函数：仍然需要手动实现，因为 unique_ptr 不能复制
    DocConfig(const DocConfig& other) : version(other.version), is_encrypted(other.is_encrypted) {
        if (other.author) {
            size_t len = strlen(other.author.get());
            author = std::make_unique<char[]>(len + 1);
            strcpy(author.get(), other.author.get());
        } else {
            author = nullptr;
        }
        std::cout << "DocConfig copied for author: " << (author ? author.get() : "N/A") << std::endl;
    }

    // 赋值运算符：仍然需要手动实现
    DocConfig& operator=(const DocConfig& other) {
        if (this == &other) return *this;
        // unique_ptr 会自动处理旧资源的释放
        if (other.author) {
            size_t len = strlen(other.author.get());
            author = std::make_unique<char[]>(len + 1);
            strcpy(author.get(), other.author.get());
        } else {
            author = nullptr;
        }
        version = other.version;
        is_encrypted = other.is_encrypted;
        std::cout << "DocConfig assigned for author: " << (author ? author.get() : "N/A") << std::endl;
        return *this;
    }

    // 析构函数现在可以由 unique_ptr 自动管理 author，但 DocConfig 自身仍然需要一个
    // （如果不是 trivial 类型，编译器会生成，但现在我们显式声明它，并让 unique_ptr 完成工作）
    ~DocConfig() {
        std::cout << "DocConfig destroyed for author: " << (author ? author.get() : "N/A") << std::endl;
    }

    // 可以添加移动构造函数和移动赋值运算符，让 DocConfig 更好地支持移动语义
    DocConfig(DocConfig&& other) noexcept
        : author(std::move(other.author)), version(other.version), is_encrypted(other.is_encrypted) {
        std::cout << "DocConfig moved (constructor) from author: " << (author ? author.get() : "N/A") << std::endl;
    }

    DocConfig& operator=(DocConfig&& other) noexcept {
        if (this == &other) return *this;
        author = std::move(other.author);
        version = other.move(other.version);
        is_encrypted = other.is_encrypted;
        std::cout << "DocConfig moved (assignment) from author: " << (author ? author.get() : "N/A") << std::endl;
        return *this;
    }
};

第二步：重构 DocumentProcessor 内部的成员变量

• char* doc_content 替换为 std::unique_ptr<char[]>。
• DocConfig* config 替换为 std::unique_ptr<DocConfig>，明确 DocumentProcessor 独占 DocConfig。
• FILE* log_file 替换为 std::unique_ptr<FILE, decltype(&fclose)>，并提供自定义删除器 fclose。

// 自定义删除器 for FILE*
struct FileCloser {
    void operator()(FILE* fp) const {
        if (fp) {
            std::cout << "Closing log file via custom deleter." << std::endl;
            fclose(fp);
        }
    }
};

class DocumentProcessor {
private:
    std::unique_ptr<char[]> doc_content; // 智能指针管理文档内容
    size_t content_size;
    std::unique_ptr<DocConfig> config; // 智能指针管理文档配置
    std::unique_ptr<FILE, FileCloser> log_file; // 智能指针管理文件句柄，带自定义删除器

public:
    // 构造函数现在接收 unique_ptr 作为参数，表明所有权转移
    DocumentProcessor(size_t size, std::unique_ptr<DocConfig> cfg, const char* log_filename)
        : content_size(size), config(std::move(cfg)) { // 移动所有权
        // doc_content 的分配
        doc_content = std::make_unique<char[]>(size);
        memset(doc_content.get(), 0, size); // 初始化为0

        // log_file 的分配
        if (log_filename) {
            FILE* fp = fopen(log_filename, "a");
            if (!fp) {
                std::cerr << "Failed to open log file: " << log_filename << std::endl;
                // 注意：如果这里抛出异常，doc_content 和 config 会被其 unique_ptr 自动释放，实现了异常安全！
                throw std::runtime_error("Log file error!");
            }
            log_file = std::unique_ptr<FILE, FileCloser>(fp, FileCloser{}); // 绑定自定义删除器
        }
        std::cout << "DocumentProcessor created with content size " << size << std::endl;
    }

    // 析构函数现在变得非常简洁，所有资源都由智能指针自动管理
    ~DocumentProcessor() {
        std::cout << "DocumentProcessor destroyed." << std::endl;
    }

    void processData(const char* data, size_t len) {
        if (len >= content_size) {
            std::cerr << "Data too large for buffer!" << std::endl;
            return;
        }
        strcpy(doc_content.get(), data); // 使用 get() 访问裸指针
        if (config->is_encrypted) { // 智能指针可以直接用 -> 访问成员
            std::cout << "Encrypting data..." << std::endl;
        }
        if (log_file) { // unique_ptr 可以直接用作布尔条件判断是否为空
            fprintf(log_file.get(), "Processed by %s (v%d): %sn", config->author.get(), config->version, data);
            fflush(log_file.get());
        }
        std::cout << "Data processed: " << doc_content.get() << std::endl;
    }

    // getConfig() 现在返回一个对 DocConfig 的引用，不转移所有权
    // 如果需要外部共享，可能返回 std::shared_ptr<DocConfig>，但这里仍是独占的
    const DocConfig& getConfig() const {
        return *config; // 解引用智能指针以获取实际对象
    }

    // 阻止复制，因为 unique_ptr 成员不能复制
    DocumentProcessor(const DocumentProcessor&) = delete;
    DocumentProcessor& operator=(const DocumentProcessor&) = delete;

    // 可以添加移动构造函数和移动赋值运算符
    DocumentProcessor(DocumentProcessor&& other) noexcept = default;
    DocumentProcessor& operator=(DocumentProcessor&& other) noexcept = default;
};

第三步：重构工厂函数 createDefaultProcessor

工厂函数应该返回 std::unique_ptr<DocumentProcessor>，将所有权明确地转移给调用者。

// 独立的工厂函数 (或者作为静态成员函数)
std::unique_ptr<DocumentProcessor> createDefaultProcessor(size_t size, const char* log_path) {
    auto default_cfg = std::make_unique<DocConfig>("Default Author", 1, false);
    // 使用 std::make_unique 创建 DocumentProcessor 实例
    return std::make_unique<DocumentProcessor>(size, std::move(default_cfg), log_path);
}

第四步：重构 run_legacy_system 函数

现在，main 函数或 run_legacy_system 函数将使用智能指针来管理 DocumentProcessor 实例，从而确保异常安全和自动资源释放。

void run_refactored_system() {
    std::cout << "n--- Running Refactored System ---" << std::endl;
    std::unique_ptr<DocConfig> my_config = std::make_unique<DocConfig>("Alice", 2, true);
    std::unique_ptr<DocumentProcessor> processor = nullptr; // 初始化为nullptr

    try {
        // 创建 DocumentProcessor，并将 my_config 的所有权移动给它
        processor = std::make_unique<DocumentProcessor>(256, std::move(my_config), "app_log.txt");

        processor->processData("Hello World Refactored Document.", 100);

        // 假设这里抛出异常
        // throw std::runtime_error("Processing failed in refactored system!");

    } catch (const std::exception& e) {
        std::cerr << "Refactored system error: " << e.what() << std::endl;
        // 即使发生异常，processor 和其内部的资源（doc_content, config, log_file）也会被自动释放
        // my_config 即使没有被 move 成功，也会在离开 try 块时自动释放
    }
    // 离开作用域时，processor 会自动销毁，无需手动 delete
    std::cout << "--- Refactored System Finished ---n" << std::endl;
}

int main() {
    run_legacy_system(); // 运行一次旧代码，观察问题
    std::cout << "--------------------------------n" << std::endl;
    run_refactored_system(); // 运行重构后的代码，观察健壮性

    // 验证 my_config 在 move 之后是否为空
    // if (my_config) { // 在 run_refactored_system 内部，my_config 已经被 move 为空
    //     std::cout << "my_config is still valid." << std::endl;
    // } else {
    //     std::cout << "my_config has been moved/nullptr." << std::endl;
    // }

    return 0;
}

3.2.3 引入 std::shared_ptr 的场景 (可选扩展)

假设现在我们的 DocumentProcessor 内部的 DocConfig 不再是独占的，而是需要被多个 DocumentProcessor 实例共享，或者被一个全局的配置管理器共享。这时，std::shared_ptr 就派上用场了。

// 假设 DocConfig 现在可以被多个处理器共享
// 原始 DocConfig 类需要确保其拷贝构造函数和赋值运算符正确处理 unique_ptr<char[]>
// 或者直接将 char* author 替换为 std::string，这样就无需手动管理内存和实现大三/大五法则了。
// 为了简化，我们假设 DocConfig 的 author 字段已经是一个 std::string

struct SharedDocConfig {
    std::string author; // 使用 std::string 简化内存管理
    int version;
    bool is_encrypted;

    SharedDocConfig(const std::string& auth, int ver, bool encrypted)
        : author(auth), version(ver), is_encrypted(encrypted) {
        std::cout << "SharedDocConfig created for author: " << author << std::endl;
    }
    ~SharedDocConfig() {
        std::cout << "SharedDocConfig destroyed for author: " << author << std::endl;
    }
};

class SharedDocumentProcessor {
private:
    std::unique_ptr<char[]> doc_content;
    size_t content_size;
    std::shared_ptr<SharedDocConfig> config; // 共享配置
    std::unique_ptr<FILE, FileCloser> log_file;

public:
    SharedDocumentProcessor(size_t size, std::shared_ptr<SharedDocConfig> cfg, const char* log_filename)
        : content_size(size), config(std::move(cfg)) { // 移动共享指针，增加引用计数
        doc_content = std::make_unique<char[]>(size);
        memset(doc_content.get(), 0, size);

        if (log_filename) {
            FILE* fp = fopen(log_filename, "a");
            if (!fp) {
                std::cerr << "Failed to open log file: " << log_filename << std::endl;
                throw std::runtime_error("Log file error!");
            }
            log_file = std::unique_ptr<FILE, FileCloser>(fp, FileCloser{});
        }
        std::cout << "SharedDocumentProcessor created with content size " << size << std::endl;
    }

    ~SharedDocumentProcessor() {
        std::cout << "SharedDocumentProcessor destroyed." << std::endl;
    }

    void processData(const char* data, size_t len) {
        if (len >= content_size) {
            std::cerr << "Data too large for buffer!" << std::endl;
            return;
        }
        strcpy(doc_content.get(), data);
        if (config->is_encrypted) {
            std::cout << "Encrypting data..." << std::endl;
        }
        if (log_file) {
            fprintf(log_file.get(), "Processed by %s (v%d): %sn", config->author.c_str(), config->version, data);
            fflush(log_file.get());
        }
        std::cout << "Data processed: " << doc_content.get() << std::endl;
    }

    // 允许获取共享配置的 shared_ptr
    std::shared_ptr<SharedDocConfig> getConfig() const {
        return config;
    }
};

void run_shared_system() {
    std::cout << "n--- Running Shared System ---" << std::endl;
    // 创建一个共享配置
    auto shared_cfg = std::make_shared<SharedDocConfig>("Global Admin", 5, true);

    // 两个处理器共享同一个配置
    auto proc1 = std::make_unique<SharedDocumentProcessor>(128, shared_cfg, "shared_log1.txt");
    auto proc2 = std::make_unique<SharedDocumentProcessor>(256, shared_cfg, "shared_log2.txt");

    proc1->processData("First document for global admin.", 50);
    proc2->processData("Second document for global admin.", 80);

    // 此时 shared_cfg 的引用计数是 3 (proc1, proc2, 自身)

    // 离开作用域时，proc1, proc2 销毁，shared_cfg 引用计数降为 1。
    // 最后 shared_cfg 自身销毁，引用计数降为 0，SharedDocConfig 对象被释放。
    std::cout << "--- Shared System Finished ---n" << std::endl;
}

3.2.4 std::weak_ptr 解决循环引用

std::weak_ptr 的主要用途是打破 std::shared_ptr 之间的循环引用。考虑一个父子关系：父节点拥有子节点的 shared_ptr，子节点也想持有父节点的引用。如果子节点也用 shared_ptr 引用父节点，就会形成循环。

#include <iostream>
#include <memory>
#include <vector>
#include <string>

class Child; // 前向声明

class Parent {
public:
    std::string name;
    std::vector<std::shared_ptr<Child>> children; // 父拥有子

    Parent(const std::string& n) : name(n) {
        std::cout << "Parent " << name << " created." << std::endl;
    }
    ~Parent() {
        std::cout << "Parent " << name << " destroyed." << std::endl;
    }

    void addChild(std::shared_ptr<Child> child);
};

class Child {
public:
    std::string name;
    // std::shared_ptr<Parent> parent; // 问题：如果用 shared_ptr，会形成循环引用
    std::weak_ptr<Parent> parent; // 解决循环引用：子观察父

    Child(const std::string& n) : name(n) {
        std::cout << "Child " << name << " created." << std::endl;
    }
    ~Child() {
        std::cout << "Child " << name << " destroyed." << std::endl;
    }

    void setParent(std::shared_ptr<Parent> p) {
        parent = p; // weak_ptr 不增加引用计数
    }

    void showParent() const {
        if (auto p_locked = parent.lock()) { // 尝试获取 shared_ptr
            std::cout << "Child " << name << "'s parent is " << p_locked->name << std::endl;
        } else {
            std::cout << "Child " << name << "'s parent no longer exists." << std::endl;
        }
    }
};

void Parent::addChild(std::shared_ptr<Child> child) {
    children.push_back(child);
    child->setParent(std::shared_ptr<Parent>(this)); // 注意：这里需要从 this 创建一个 shared_ptr
                                                      // 正确的做法是 Parent 自身也是 shared_ptr
                                                      // 或者 Child 接收 shared_ptr<Parent>
}

// 更好的做法是 Parent 自身也是 shared_ptr 管理的
// 并且使用 std::enable_shared_from_this 机制
class ParentV2 : public std::enable_shared_from_this<ParentV2> {
public:
    std::string name;
    std::vector<std::shared_ptr<Child>> children;

    ParentV2(const std::string& n) : name(n) {
        std::cout << "ParentV2 " << name << " created." << std::endl;
    }
    ~ParentV2() {
        std::cout << "ParentV2 " << name << " destroyed." << std::endl;
    }

    void addChild(std::shared_ptr<Child> child) {
        children.push_back(child);
        child->setParent(shared_from_this()); // 使用 shared_from_this 获取自身的 shared_ptr
    }
};

void run_weak_ptr_example() {
    std::cout << "n--- Running Weak Ptr Example ---" << std::endl;
    std::shared_ptr<ParentV2> parent = std::make_shared<ParentV2>("Father");
    std::shared_ptr<Child> child1 = std::make_shared<Child>("Son 1");
    std::shared_ptr<Child> child2 = std::make_shared<Child>("Daughter 2");

    parent->addChild(child1);
    parent->addChild(child2);

    child1->showParent();
    child2->showParent();

    // 此时 parent 的引用计数为 1 (父对象自身)
    // child1 和 child2 的引用计数为 1 (父对象的 children 向量)
    // ParentV2 内部通过 shared_from_this() 创建的 shared_ptr 也会增加引用计数
    // 所以 ParentV2 引用计数是 1 + 2 = 3
    // 但 child1 和 child2 内部的 weak_ptr 不增加引用计数。

    // 当 parent 离开作用域时，它的 shared_ptr 销毁，引用计数减少。
    // children 向量中的 shared_ptr 也会销毁，引用计数进一步减少。
    // 最终 ParentV2 对象被销毁。
    // 然后 child1 和 child2 离开作用域时，它们的 shared_ptr 销毁，引用计数变为 0，Child 对象被销毁。

    std::cout << "--- Weak Ptr Example Finished ---n" << std::endl;
}

3.2.5 重构前后对比

特性	原始C风格代码	重构后使用智能指针的代码
内存管理	手动 new/delete 或 malloc/free，易错，需手动处理数组和自定义资源	自动管理，std::unique_ptr 和 std::shared_ptr 自动释放内存，unique_ptr 可指定自定义删除器处理非内存资源
异常安全	易受异常影响，可能导致内存泄漏或资源泄漏	天生具备异常安全，即使抛出异常，栈上智能指针也会自动销毁并释放资源
所有权语义	模糊不清，裸指针可能指向已释放内存，或被多次释放	清晰明确：unique_ptr 独占，shared_ptr 共享，weak_ptr 观察
双重释放	常见错误，导致未定义行为或崩溃	智能指针内部机制避免双重释放
悬空指针	释放后裸指针仍存在，使用时危险	unique_ptr 移走所有权后源指针置空；shared_ptr 引用计数归零后释放；weak_ptr 转换为 shared_ptr 失败则安全
代码量/复杂性	需手动实现析构函数、复制/移动构造函数和赋值运算符（大三/大五法则）	显著减少，无需手动管理资源，特别是对于 unique_ptr 成员，编译器可自动生成移动操作
可维护性	难以调试，错误隐蔽，维护成本高	错误更少，逻辑更清晰，易于理解和维护
性能	unique_ptr 通常与裸指针无异，shared_ptr 略有引用计数开销	unique_ptr 零开销抽象，shared_ptr 少量引用计数开销，但通常可接受

第四部分：高级考量与最佳实践

4.1 智能指针的性能考量

• std::unique_ptr： 几乎没有运行时开销，它的大小和行为与裸指针相同（除了移动操作）。是C++中实现RAII的最轻量级方式。
• std::shared_ptr： 存在一定的性能开销。
  • 内存开销： shared_ptr 对象通常是裸指针大小的两倍，因为它需要存储一个指向资源对象的指针和一个指向控制块（包含引用计数和弱引用计数）的指针。
  • CPU开销： 引用计数的增减通常是原子操作，以保证线程安全。原子操作比非原子操作略慢。std::make_shared 通常比 std::shared_ptr(new T(...)) 更高效，因为它能在一个内存块中同时分配对象和控制块，减少一次堆分配。

建议： 优先使用 std::unique_ptr。只有当确实需要共享所有权时，才考虑使用 std::shared_ptr。

4.2 get() 和 release() 的使用与警惕

• get()： 返回智能指针所持有的裸指针。常用于需要与C API交互的场景，C API可能需要裸指针作为参数。
  • 注意： 不要使用 delete 或 free get() 返回的指针，因为智能指针仍然拥有该资源，会在其生命周期结束时自动释放。这会导致双重释放。
  • 示例： FILE* fp = unique_ptr_file.get(); fwrite(data, 1, size, fp);
• release()： 放弃智能指针对资源的拥有权，并返回裸指针。智能指针会变为空。调用者现在需要手动管理这个裸指针。
  • 警惕： 这是一个危险的操作，因为它将内存管理的责任重新交给了程序员。只在极少数情况下使用，比如将资源所有权转移给一个C API，而该API将负责释放资源。
  • 示例： char* raw_buffer = unique_ptr_buffer.release(); // 此时 unique_ptr_buffer 变为空
free(raw_buffer); // 需要手动释放

4.3 自定义删除器

std::unique_ptr 和 std::shared_ptr 都支持自定义删除器。这使得它们不仅可以管理堆内存，还可以管理任何需要配对获取/释放操作的资源。

• unique_ptr 的自定义删除器： 删除器是类型的一部分，所以不同删除器的 unique_ptr 类型不同。
  • std::unique_ptr<FILE, void(*)(FILE*)>
  • std::unique_ptr<HANDLE, decltype(&CloseHandle)> (Windows API)
  • 函数对象或Lambda表达式作为删除器更灵活。

// 示例：unique_ptr 管理 C 风格的 malloc/free 内存
auto malloc_deleter = [](char* p) {
    std::cout << "Calling custom malloc_deleter." << std::endl;
    std::free(p);
};
std::unique_ptr<char, decltype(malloc_deleter)> buffer_ptr(
    (char*)std::malloc(100), malloc_deleter
);
// buffer_ptr 离开作用域时，malloc_deleter 会被调用

• shared_ptr 的自定义删除器： 删除器不是类型的一部分，可以有不同删除器的 shared_ptr 指向相同类型。
  • std::shared_ptr<FILE> file_ptr(fopen("log.txt", "w"), [](FILE* fp){ fclose(fp); });

4.4 永远使用 std::make_unique 和 std::make_shared

• 异常安全： std::make_unique 和 std::make_shared 是异常安全的。
  • 考虑 std::shared_ptr<Widget> ptr(new Widget(), new AnotherResource());
  • 如果 new Widget() 成功，new AnotherResource() 失败并抛出异常，那么 Widget 的内存将泄漏，因为 shared_ptr 构造函数还未完成，无法管理 Widget。
  • std::make_shared<Widget>() 将一次性分配内存，并完全构建 Widget 对象和控制块，从而避免这种潜在的泄漏。
• 性能： 对于 std::shared_ptr，std::make_shared 避免了两次堆分配（一次给对象，一次给控制块），而是进行一次组合分配，效率更高。
• std::make_unique 在C++14中引入，提供了类似的便利和异常安全优势。

4.5 智能指针与C API的交互

当需要将智能指针持有的资源传递给期望裸指针的C API时，使用 get() 方法是安全的。

extern "C" {
    void c_api_process_buffer(char* buffer, int size);
}

void process_with_c_api(std::unique_ptr<char[]> buffer, int size) {
    // get() 返回裸指针，但不放弃所有权
    c_api_process_buffer(buffer.get(), size);
    // buffer 离开作用域时会自动释放
}

如果C API会接管资源的所有权并负责释放，则使用 release()，但务必确保C API确实会释放资源。

4.6 避免裸指针和智能指针混用带来的混乱

一旦开始使用智能指针，应尽量避免在同一生命周期内混用裸指针。如果一个对象由智能指针管理，那么任何对该对象的引用都应该通过智能指针（或引用）进行，而不是通过裸指针，除非是在与C API交互或进行临时观察（且确定生命周期不会结束）的非常受限的场景。

结语

智能指针是现代C++中不可或缺的工具。它们不仅仅是内存管理的自动化器，更是代码设计理念的一次飞跃。通过采纳std::unique_ptr、std::shared_ptr和std::weak_ptr，我们能够清晰地表达资源的所有权语义，极大地增强程序的健壮性，有效避免了C风格代码中常见的内存泄漏、悬空指针和异常安全问题。

重构旧代码是一个挑战，但也是一次提升系统质量和可维护性的绝佳机会。希望本次讲座为您提供了清晰的重构路径、实用的代码示例和深入的思考，助您在未来的编程实践中，构建出更加坚固、可靠、优雅的C++应用。让我们共同拥抱现代C++的强大力量，编写更高质量的代码！