如何写出合格的C++构造和析构函数

编码时空的诗意行者

已于 2024-07-03 16:34:14 修改

阅读量871

点赞数 14

分类专栏： C/C++知识文章标签： c++ 开发语言

于 2024-07-03 15:50:31 首次发布

本文链接：https://blog.csdn.net/hebhljdx/article/details/140153729

版权

C/C++知识专栏收录该内容

27 篇文章 0 订阅

订阅专栏

笔者曾经在团队中发现有人在构造函数中读取文件配置，导致界面创建速度降低了一个数量级。由此引发笔者想讨论如何写一个合格的构造和析构函数文章的想法。

在C++中，构造函数和析构函数是类的基础组成部分，它们分别负责对象的初始化和清理，也是C++RAII(Resource Acquisition Is Initialization)的核心体现。不当的使用可能引发多种问题，包括资源泄漏、未定义行为、程序崩溃等。
由此可见安全地编写C++的构造函数和析构函数不是一件容易的使其，以下我们一起探讨一下这方面的最佳实践。

禁止抛出异常

构造函数中抛出异常时，已经构造的部分会被析构，这会导致资源泄露。我们可以noexcept 确保析构函数应该不抛出异常。
示例代码：

class MyClass {
public:
    MyClass() noexcept {
        // 不抛出异常的初始化代码
    }
    ~MyClass() noexcept {
        // 不抛出异常的清理代码
    }
};

禁止进行同步操作

避免在构造和析构函数中使用锁或其他可能导致死锁的同步机制。
在多线程程序中，锁和其他同步机制用于控制对共享资源的并发访问，以防止数据竞争和其他并发错误。
在构造函数和析构函数中使用锁时需要格外小心，因为这可能导致死锁或其他同步问题。

死锁的风险

死锁是指两个或多个线程在等待对方释放锁，而导致都无法继续执行的情况。在构造和析构函数中使用锁时，可能会无意中引入死锁的风险：

构造函数中的死锁：如果在构造函数中获取锁，并且在持有锁的同时调用了可能再次尝试获取同一锁的代码（例如，一个回调函数或者虚函数调用），这可能导致死锁。
析构函数中的死锁：析构函数通常在对象生命周期结束时被调用，这可能是在析构其他对象的过程中，或者在释放资源的过程中。如果在析构函数中尝试获取锁，而这个锁已经被同一线程中正在析构的其他对象持有，或者被其他线程中的对象持有，并且那些线程正在等待当前线程释放一个它们需要的资源，则可能发生死锁。

为了避免这些问题，应当在设计阶段就考虑如何管理对象生命周期和同步。以下是一些具体的建议：

尽量不在构造和析构中做同步操作：如果可能，避免在构造和析构函数中进行任何形式的同步操作。相反，考虑将同步操作移至对象的其他成员函数中。
限制构造和析构时的并发：确保对象不会在并发环境下被构造或析构，或者通过设计确保在对象的构造和析构过程中不会发生并发访问。
使用初始化和清理函数：可以提供单独的初始化和清理成员函数，这些函数可以在构造和析构函数之外显式调用，并在这些函数中进行必要的同步。
避免在析构函数中持有锁：如果对象的析构需要同步，考虑在析构函数之外的适当位置先释放锁，然后再销毁对象。
使用锁的层次结构：设计锁的层次结构，并确保在整个应用程序中一致地遵循它们，以避免死锁。

示例代码

class ThreadSafeClass {
public:
    ThreadSafeClass() {
        // 初始化资源，但不获取锁
    }

    ~ThreadSafeClass() {
        // 清理资源，但不获取锁
    }

    void initialize() {
        std::lock_guard<std::mutex> lock(mutex_);
        // 安全地初始化资源
    }

    void cleanup() {
        std::lock_guard<std::mutex> lock(mutex_);
        // 安全地清理资源
    }

    void doWork() {
        std::lock_guard<std::mutex> lock(mutex_);
        // 执行需要同步的工作
    }

private:
    std::mutex mutex_;
    // 其他资源和成员
};

在上面代码中，构造函数和析构函数不进行任何同步操作。而是提供了initialize和cleanup成员函数来在对象的生命周期的适当时机进行安全的同步操作。这种方法提供了更好的控制对象状态的机会，减少了死锁的风险。

禁止文件和网络操作

在构造和析构函数中进行I/O操作可能引发异常或导致不确定行为，或者给对象的构造耗时带来负面影响，应在其他成员函数中处理I/O。

示例代码：

#include <fstream>
class MyClass {
private:
    std::fstream file;
public:
    MyClass() {
        // 不在此处打开文件
    }
    void openFile(const std::string& filename) {
        file.open(filename); // 在成员函数中打开文件
    }
    ~MyClass() {
        if(file.is_open()) {
            file.close(); // 确保文件被关闭
        }
    }
};

禁止静态变量的不受控初始化

静态变量的初始化顺序是未定义的。在构造和析构函数中使用它们可能导致难以捕获的错误。

在C++中，静态变量的初始化顺序问题通常被称为“静态初始化顺序困境”（Static Initialization Order Fiasco）。这个问题源自C++程序中静态存储期对象（包括全局变量和静态变量）初始化顺序的不确定性。

循环依赖可能在全局或静态对象之间造成初始化顺序问题。避免在不同的编译单元中相互依赖的静态对象，因为这可能导致难以预测的初始化和析构顺序。

静态变量初始化顺序

C++标准规定了同一编译单元内静态变量的初始化顺序是按照它们声明的顺序进行的。然而，对于不同编译单元（通常是不同的源文件）中的静态变量，其初始化顺序是未定义的。这意味着，如果一个静态变量的初始化依赖于另一个在不同编译单元中的静态变量的值，那么程序可能会出现不正确的行为，因为你不能保证哪一个变量会先被初始化。

静态变量在构造函数和析构函数中的使用问题

当静态变量在构造函数或析构函数中使用时，如果这些静态变量是在不同的编译单元定义的，那么可能会遇到静态变量未初始化或已销毁的情况：

在构造函数中，如果你尝试访问一个还未初始化的静态变量，程序的行为将是未定义的。这可能导致程序崩溃或者不正确的行为。
在析构函数中，问题更加微妙。程序结束时，静态存储期对象的析构顺序与它们的构造顺序相反。如果一个静态变量在另一个静态变量的析构函数中被访问，而后者先于前者析构，那么这可能导致对已经销毁对象的访问。

解决方案

为了避免静态初始化顺序问题，常见的做法是使用构造函数时机的局部静态变量（也称为“Meyers’ Singleton”），这利用了C++中局部静态变量只初始化一次且是线程安全的规则：

class Singleton {
public:
    static Singleton& instance() {
        static Singleton instance; 
        return instance;
    }
private:
    Singleton() {}
};

在这个例子中，instance函数中的局部静态变量instance在第一次调用该函数时被初始化，并且在程序结束时自动销毁。这确保了无论instance函数在何处被调用，Singleton的实例都将以线程安全的方式被正确地初始化和销毁。
虽然这种做法能在一定程度上解决静态变量的副作用，但是仍然不建议使用。最好不要在构造和析构函数依赖任何静态变量。
遵循“不在构造和析构函数中使用依赖于其他编译单元静态变量”的原则，可以防止因静态初始化顺序未定义而引起的难以预料的错误。

单参数构造函数考虑使用`explicit`关键字

如果一个类定义了一个单参数构造函数，并且没有显式地使用explicit关键字，那么这个构造函数可以被编译器用于隐式类型转换。这意味着，在某些情况下，编译器可能会自动使用这个构造函数将一个不同类型的表达式转换为该类的对象，这通常是不需要或者不期望的行为。

具体来说，没有explicit关键字的单参数构造函数会导致以下几种潜在问题：

意外的类型转换：
- 编译器可能会在需要类型转换的地方自动调用这个构造函数，这可能导致逻辑错误，因为开发者可能没有意识到这种转换。
初始化列表的歧义：
- 在使用初始化列表时，如果没有explicit，编译器可能选择使用单参数构造函数而不是初始化列表，从而导致初始化行为不符合预期。
函数重载解析的歧义：
- 如果类的实例作为参数传递给一个函数，且该函数有多个重载版本，编译器可能通过使用单参数构造函数来匹配其中一个重载版本，这可能导致调用错误的函数版本。
不必要的对象创建：
- 在模板元编程中，或者在一些复杂的表达式中，这种隐式转换可能导致不必要的对象创建和销毁，影响性能。

为了避免上述问题，C++引入了explicit关键字。当一个构造函数被声明为explicit时，它就不能用于隐式转换。因此，如果想要显式地进行类型转换，你必须使用括号明确地调用构造函数，或者通过定义一个显式的转换操作符。

例如，假设我们有如下的类定义：

class MyString {
public:
    // 隐式转换允许
    MyString(int size) : m_size(size), m_data(new char[size]) {}

    // 使用explicit防止隐式转换
    explicit MyString(const char* str) : m_size(strlen(str)), m_data(new char[m_size + 1]()) {
        strcpy(m_data, str);
    }

private:
    char* m_data;
    size_t m_size;
};

在这个例子中，MyString(int size)构造函数没有使用explicit，所以它可以被用来隐式地从int转换到MyString。然而，MyString(const char* str)构造函数使用了explicit，因此它不能用于隐式转换。如果你想从const char*转换到MyString，你必须显式地调用构造函数，如下所示：

MyString s("Hello");

而不能这样：

MyString s = "Hello";  // 错误：explicit构造函数不能用于隐式转换

其他注意事项

1. 遵循三/五法则

三/五法则是C++资源管理的一个重要原则，它建议如果你为类定义了以下任何一个特殊成员函数：

析构函数
复制构造函数
复制赋值运算符

那么你也应该考虑定义另外两个与对象移动相关的特殊成员函数：

移动构造函数
移动赋值运算符

这个原则的目的是确保对象的复制和移动操作能够正确地管理资源，防止资源泄漏、重复释放等问题。

2. 资源管理

在构造函数中分配资源时，必须确保在析构函数中这些资源被正确释放。为了简化资源管理并减少错误，推荐使用RAII（Resource Acquisition Is Initialization）模式。在RAII模式中，资源的生命周期与拥有资源的对象的生命周期绑定，资源在对象构造时获取，在析构时释放。智能指针（如std::unique_ptr和std::shared_ptr）是RAII模式的典型例子。