为什么 C++ 中的析构函数？以与初始化相反的顺序取消分配内存？

Question

以与变量相反的顺序取消分配内存有什么好处？

Answer 1

考虑以下示例：

Type1 Object1;
Type2 Object2(Object1);

假设 Object2 使用 Object1 的某些内部资源，并且只要 Object1 有效，它就有效。例如，Object2 的析构函数访问 Object1 的内部资源。如果不是有逆序销毁的保证，这就会出问题。

Answer 2

这不仅仅是关于内存的释放，更是关于更广泛意义上的对称。

每次创建对象时，您都会创建一个新的工作上下文。您可以根据需要“推入”这些上下文，然后再“弹出”回来 - 对称性是必要的。

当涉及到 RAII 和异常安全，或者证明前置条件和后置条件的正确性时，这是一种非常强大的思维方式（构造函数建立不变量，析构函数应该 assert() 它们，并且在精心设计的类中每种方法都清楚地保留了它们）。

恕我直言，缺乏这个功能是 Java 最大的缺陷。考虑构造函数打开文件句柄或互斥体或其他任何东西的对象 - Armen 的答案出色地说明了这种对称性如何强制执行一些常识性约束（Java 等语言可能会让 Object1 在 Object2 之前超出范围，但 Object2 通过引用计数使 Object1 保持活动状态），但是从对象生命周期的角度考虑时，有大量的设计问题可以很好地解决。

当您牢记这一点时，许多 C++ 陷阱就会自行解释

• 为什么 goto 不能交叉初始化
• 为什么建议您在任何函数中只使用一个 return（这仅适用于非 RAII 语言，例如 C 和 Java）
• 为什么异常是构造函数失败的唯一合理方式，同样为什么析构函数永远无法合理地抛出
• 异常不应在构造函数

等 中调用虚函数 ETC...

Answer 3

局部变量的销毁顺序的保证是允许您编写（例如）如下代码：

{
    LockSession s(lock);
    std::ofstream output("filename");

    // write stuff to output
}

LockSession 是一个在其构造函数中获取锁并在其析构函数中释放它的类。

在 } 处，我们知道文件句柄将在释放锁之前关闭（并刷新），如果还有其他线程，这是一个非常有用的保证在使用相同锁来保护对同一文件的访问的程序中。

假设标准没有指定销毁顺序，那么我们就必须担心此代码可能会释放锁（允许其他线程访问该文件），然后才开始刷新并关闭它。或者为了保持我们需要的保证，我们必须编写这样的代码：

{
    LockSession s(lock);
    {
        std::ofstream output("filename");

        // write stuff to output

    } // closes output
} // releases lock

这个示例并不完美 - 刷新文件并不能保证真正成功，因此依赖 ofstream 析构函数来执行此操作不会导致在这方面产生防弹代码。但即使存在这个问题，我们至少可以保证在释放锁时我们不会再打开文件，一般来说，这是销毁顺序可以提供的那种有用的保证。

C++ 中还有其他销毁顺序的保证，例如，基类子对象在派生类析构函数运行后被销毁，对象的数据成员也在派生类析构函数运行后以与构造相反的顺序销毁并在基类子对象之前。每个保证都存在，以便您可以编写以某种方式依赖于第二个东西仍然存在而第一个东西被破坏的代码。

这些都与内存的实际解除分配没有太大关系，更多的是关于析构函数的作用。不过，既然您询问了解除分配的问题，那么在某些情况下，某些内存分配器实现可能会受益于以与分配相反的顺序释放块。它可以使分配器通过合并相邻的空闲块更容易地减少内存碎片。不过，您并不经常需要考虑这一点，无论如何，需要合并空闲块的分配器应该足够聪明，无论分配和释放的顺序如何，都应该足够聪明。