析构函数什么时候调用;析构函数什么时候调用？可以为虚函数吗 收藏 0

Effective C++ 条款09 绝不在构造和析构过程中调用virtual函数

条款开始前我要先阐述重点：你不该在构造函数和析构函数期间调用virtual函数，因为这样的调用不会带来你预想的结果，就算有你也不会高兴。如果你同时也是一位Java或C#程序员，请更加注意本条款，因为这是C++与它们不相同的一个地方。

假设你有个class继承体系，用来塑模股市交易如买进、卖出的订单等等。这样的交易一定要经过审计，所以每当创建一个交易对象，在审计日志(audit log)中也需要创建一笔适当记录。下面是一个看起来颇为合理的做法：

现在，当以下这行被执行，会发生什么事：

无疑地会有一个BuyTransaction构造函数被调用，但首先Transaction构造函数一定会更早被调用：是的，derived class对象内的base class成分会在derived class自身成分被构造之前先构造妥当。Transaction构造函数的最后一行调用virtual函数logTransaction，这正是引发惊奇的起点。这时候被调用的logTransaction是Transaction内的版本，不是BuyTransaction内的版本——即使目前即将建立的对象类型是BuyTransaction。是的，base class构造期间virtual函数绝不会下降到derived classes阶层。取而代之的是，对象的作为就像隶属base类型一样。非正式的说法或许比较传神：在base class构造期间，virtual函数不是virtual函数。

这一似乎反直觉的行为有个好理由。由于base class构造函数的执行更早于derived class构造函数，当base class构造函数执行时derived class的成员变量尚未初始化。如果此期间调用的virtual函数下降至derived classes阶层，要知道derived class的函数几乎必然取用local成员变量，而那些成员变量尚未初始化。这将是一张通往不明确行为和彻夜调试大会串的直达车票。“要求使用对象内部尚未初始化的成分”是危险的代名词，所以C++不让你走这条路。

其实还有比上述理由更根本的原因：在derived class对象的base class构造期间，对象的类型是base class而不是derived class。不只virtual函数会被编译器解析至(resolve to)base class，若使用运行期类型信息(runtime type information，例如dynamic_cast(见条款27)和typeid)，也会把对象视为base class类型。本例之中，当Transaction构造函数正执行起来打算初始化“BuyTransaction对象内的base class成分”时，该对象的类型是Transaction。那是每一个C++次成分(见条款1)的态度，而这样的对待是合理的：这个对象内的“BuyTransaction专属成分”尚未被初始化，所以面对它们，最安全的做法就是视它们不存在。对象在derived class构造函数开始执行前不会成为一个derived class对象。

相同道理也适用于析构函数。一旦derived class析构函数开始执行，对象内的derived class成员变量便呈现未定义值，所以C++视它们仿佛不再存在。进入base class析构函数后对象就成为一个base class对象，而C++的任何部分包括virtual函数、dynamic_casts等等也就那么看待它。

在上述示例中，Transaction构造函数直接调用一个virtual函数，这很明显而且容易看出违反本条款。由于它很容易被看出来，某些编译器会为此发出一个警告信息(某些则否，见条款53对警告信息的讨论)。即使没有这样的警告，这个问题在执行前也几乎肯定会变得显而易见，因为logTransaction函数在Transaction内是个pure virtual。除非它被定义(不太有希望，但是有可能，见条款34)否则程序无法连接，因为连接器找不到必要的Transaction::logTransaction实现代码。

但是侦测“构造函数或析构函数运行期间是否调用virtual函数”并不总是这般轻松。如果Transaction有多个构造函数，每个都需执行某些相同工作，那么避免代码重复的一个优秀做法是把共同的初始化代码(其中包括对logTransaction的调用)放进一个初始化函数如init内：

这段代码概念上和稍早版本相同，但它比较潜藏并且暗中为害，因为它通常不会引发任何编译器和连接器的抱怨。此时由于logTransaction是Transaction内的一个pure virhual函数，当pure virtual函数被调用，大多执行系统会中止程序(通常会对此结果发出一个信息)。然而如果logTransaction是个正常的(也就是impure)virtual函数并在Transaction内带有一份实现代码，该版本就会被调用，而程序也就会兴高采烈地继续向前行，留下你百思不解为什么建立一个derived class对象时会调用错误版本的logTransaction。唯一能够避免此问题的做法就是：确定你的构造函数和析构函数都没有(在对象被创建和被销毁期间)调用virtual函数，而它们调用的所有函数也都服从同一约束。

但你如何确保每次一有Transaction继承体系上的对象被创建，就会有适当版本的logTransaction被调用呢？很显然，在Transaction构造函数(s)内对着对象调用virtual函数是一种错误做法。

其他方案可以解决这个问题。一种做法是在class Transaction内将logTransaction函数改为non-virtual，然后要求derived class构造函数传递必要信息给Transaction构造函数，而后那个构造函数便可安全地调用non-virtual logTransaction。像这样：

换句话说由于你无法使用virtual函数从base classes向下调用，在构造期间，你可以藉由“令 derived classes 将必要的构造信息向上传递至base class 构造函数”替换之而加以弥补。

请注意本例之BuyTransaction内的private static函数createLogString的运用。是的，比起在成员初值列(member initialization list)内给予base class所需数据，利用辅助函数创建一个值传给base class构造函数往往比较方便(也比较可读)。令此函数为 static，也就不可能意外指向“初期未成熟之BuyTransaction对象内尚未初始化的成员变量”。这很重要，正是因为“那些成员变量处于未定义状态”，所以“在base class构造和析构期间调用的virtual函数不可下降至derived classes”。

请记住

■ 在构造和析构期间不要调用virtual函数，因为这类调用从不下降至derived class(比起当前执行构造函数和析构函数的那层)。

C++程序员必须掌握，为什么有些析构函数也要被定义为虚函数？

在阅读C++项目（caffe）源码时，发现不少基类不仅把常规的成员函数定义成虚函数（virtual），也会把析构函数定义为虚函数，结合前面几节的介绍，稍稍思考下，这样做的确是有原因的，本文将结合C++代码实例尝试探讨下。

为什么要把析构函数定义为虚函数？

随便写一段C++代码作为实例，在这个例子中，我们先不把析构函数定义为虚函数：

这段代码的逻辑很简单，无非就是定义了两个类：类 Base 的成员函数 foo() 为虚函数，构造函数和析构函数都是常规函数，此外它还有个 public 的成员变量 buf。类 Child 则公开继承了 Base，因此它可以直接使用 Base::buf——在构造函数中 new 了一段内存，并且在析构函数 delete 掉它。

我们直接使用 Child 实例化一个对象 c，调用 c.foo()，此时得到如下输出：

一切尽在预料中。

虽说对象 c 调用 foo() 的输出完全符合预计，但像上面那样定义类仍然是非常危险的做法。在这一节我们曾讨论过，父类指针可以调用派生类的重写函数，因此下面这两行C++代码也是合法的，请看：

编译这段C++代码完全没有问题，运行也不会报错，输出如下：

可是，从输出信息能够看出，派生类 Child 的析构函数没有被调用，对于本例而言，new 出来的 buf 没有对应的 delete，势必会造成内存泄漏。

要解决所谓的“不安全问题”，其实很简单，按照题目说的做——将基类的析构函数也定义为虚函数就可以了，请看修改后的C++代码：

也即尽在基类 Base 的析构函数前加上 virtual 关键字，其他的所有代码都无需改动。现在再执行下面的这几行C++代码：

输出如下：

显然，此时派生类 Child 的析构函数也会被调用了，内存泄漏的问题被解决了。

C++ 中的 virtual 关键字是非常好用，也是C++程序员必须掌握的关键字，其实，“不安全问题”出现的原因也是简单的：我们在静态类型与动态绑定一节中提到过，基本上只有涉及到 virtual 函数时，才会发生动态绑定，此时通过对象指针（pb）调用的函数由它指向的类（Child）决定，所以此时派生类 Child 的析构函数会被调用。如果基类 Base 的析构函数不是虚函数，那么对象指针（pb）调用的函数由其静态类型（Base）决定，也即调用的其实只是基类 Base 的析构函数而已。

别让异常逃离析构函数

《Effective C++》中的 \”别让异常逃离析构函数\” 是指在 C++ 中，当一个对象的析构函数抛出异常时，这个异常会被默认抛到外层的作用域，可能会导致程序崩溃或者出现未定义的行为。

这个问题的解决方法是在析构函数中使用 try-catch 块来处理异常，确保异常不会逃离析构函数。具体来说，可以在析构函数中捕获所有可能抛出的异常，并将它们转换成适当的异常类型或者简单地忽略它们。

此外，还可以采用资源获取即初始化（RAII）技术来避免异常逃离析构函数。RAII 技术是指在对象的构造函数中获取资源，在析构函数中释放资源，从而确保资源的正确释放。如果析构函数抛出异常，资源也会被正确释放，不会导致资源泄漏。

总之，\”别让异常逃离析构函数\” 是一个重要的 C++ 编程原则，需要程序员在编写代码时格外注意。

RAII技术是一种C++编程技术，它的全称是Resource Acquisition Is Initialization，中文意思是“资源获取即初始化”。RAII技术的核心思想是：在对象的构造函数中获取资源，在对象的析构函数中释放资源。这种技术可以避免程序中的资源泄漏和异常逃离析构函数的问题。

下面是一个简单的例子，展示了如何使用RAII技术来避免异常逃离析构函数：

在上面的例子中，我们定义了一个名为File的类，它的构造函数中打开了一个文件，如果打开失败就抛出一个异常。在析构函数中，我们关闭了文件。在main函数中，我们创建了一个File对象，并调用了它的write函数来写入一些文本。在throw语句之后，我们抛出了一个异常。由于异常被捕获了，程序会执行catch语句块中的代码，而在这个代码块中，File对象的析构函数会被自动调用，释放资源。

这个例子展示了如何使用RAII技术来避免异常逃离析构函数的问题。在实际的编程中，我们可以使用RAII技术来管理各种资源，比如内存、文件、数据库连接等。

《Effective C++》中的“绝不在构造和析构过程中调用virtual函数”是指在基类的构造函数或析构函数中调用虚函数的行为是不安全的。这是因为在派生类对象构造或析构期间，派生类对象中的基类部分可能还没有被完全构造或已经被析构。如果此时调用虚函数，那么将会调用到基类中的虚函数，而不是派生类中的实现。

这种行为可能会导致程序运行时的不可预期的错误，例如访问未初始化的数据或调用已经被析构的对象等。因此，最好避免在构造函数和析构函数中调用虚函数，而是应该使用其他的解决方案，例如将虚函数的调用延迟到对象完全构造好后再进行调用。

总之，该条规则的主要内容是在构造函数和析构函数中避免调用虚函数，以确保程序的正确性和可靠性。

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com