为什么我们需要 C++ 中的纯虚拟析构函数？

Question

我了解虚拟析构函数的需要。 但为什么我们需要一个纯虚拟析构函数？ 在一篇 C++ 文章中，作者提到当我们想要使类抽象时，我们使用纯虚析构函数。

但是我们可以通过将任何成员函数设置为纯虚函数来使类抽象。

所以我的问题是

1. 我们什么时候才能真正使析构函数成为纯虚拟的？ 有人能给出一个很好的实时例子吗？

2. 当我们创建抽象类时，将析构函数设置为纯虚函数是一个好习惯吗？ 如果是的话..那为什么？

Answer 1

1. 允许纯虚拟析构函数的真正原因可能是禁止它们意味着向语言添加另一条规则，并且不需要此规则，因为允许纯虚拟析构函数不会产生任何不良影响。

2. 不，普通的旧虚拟就足够了。

如果您创建一个具有虚拟方法默认实现的对象，并且希望使其抽象而不强迫任何人重写任何特定方法，则可以将析构函数设为纯虚拟。 我不认为这有什么意义，但这是可能的。

请注意，由于编译器将为派生类生成隐式析构函数，因此如果类的作者不这样做，则任何派生类都将不是抽象的。 因此，在基类中拥有纯虚拟析构函数不会对派生类产生任何影响。 它只会使基类抽象（感谢 @kappa 的评论）。

人们还可能假设每个派生类可能需要具有特定的清理代码，并使用纯虚拟析构函数作为编写代码的提醒，但这似乎是人为的（并且是非强制的）。

注意：析构函数是唯一的方法，即使它是纯虚拟必须有一个实现，以便实例化派生类（是的纯虚函数可以有实现，纯虚意味着派生类必须重写此方法，这与实现是正交的）。

struct foo {
    virtual void bar() = 0;
};

void foo::bar() { /* default implementation */ }

class foof : public foo {
    void bar() { foo::bar(); } // have to explicitly call default implementation.
};

Answer 2

对于一个抽象类来说，你所需要的只是至少一个纯虚函数。 任何函数都可以； 但事实上，析构函数是任何类都会有的东西，所以它总是作为候选者存在。 此外，使析构函数成为纯虚拟的（而不是仅仅虚拟的）除了使类抽象之外没有任何行为副作用。 因此，许多风格指南建议一致地使用纯虚拟析构函数来指示类是抽象的——如果没有其他原因，它提供了一个一致的位置，让阅读代码的人可以查看该类是否是抽象的。

Answer 3

如果您想创建一个抽象基类：

• 无法实例化（是的，这对于术语“抽象”来说是多余的！）
• 但是需要虚拟析构函数行为（您打算携带指向 ABC 的指针而不是指向派生类型的指针，并通过它们进行删除），
• 但其他方法不需要任何其他虚拟调度行为（也许有有 没有其他方法吗？考虑一个简单的受保护的“资源”容器，它需要构造函数/析构函数/赋值，但没有太多其他方法）

...最简单的方法是通过使析构函数成为纯虚拟函数来使类抽象和 为其提供定义（方法体）。

对于我们假设的 ABC：

您保证它不能被实例化（即使是在类本身内部，这就是为什么私有构造函数可能还不够），您可以获得析构函数所需的虚拟行为，并且您不必查找和将另一个不需要虚拟调度的方法标记为“虚拟”。

Answer 4

这里我想告诉一下我们什么时候需要虚析构函数，什么时候需要纯虚析构函数

class Base
{
public:
    Base();
    virtual ~Base() = 0; // Pure virtual, now no one can create the Base Object directly 
};

Base::Base() { cout << "Base Constructor" << endl; }
Base::~Base() { cout << "Base Destructor" << endl; }


class Derived : public Base
{
public:
    Derived();
    ~Derived();
};

Derived::Derived() { cout << "Derived Constructor" << endl; }
Derived::~Derived() {   cout << "Derived Destructor" << endl; }


int _tmain(int argc, _TCHAR* argv[])
{
    Base* pBase = new Derived();
    delete pBase;

    Base* pBase2 = new Base(); // Error 1   error C2259: 'Base' : cannot instantiate abstract class
}

1. 当你希望没有人能够创建Base类的对象时直接使用纯虚拟析构函数virtual ~Base() = 0。 通常至少需要一个纯虚函数，让我们以virtual ~Base() = 0作为这个函数。

2. 当你不需要上面的东西时，只需要派生类对象的安全销毁

   Base* pBase = new Derived();
   删除pBase；
   不需要纯虚析构函数，只有虚析构函数就可以完成这项工作。

Answer 5

从我读到的你的问题的答案中，我无法推断出实际使用纯虚拟析构函数的充分理由。 例如，下面的理由根本不能说服我：

允许纯虚拟析构函数的真正原因可能是禁止它们意味着向语言添加另一条规则，并且不需要此规则，因为允许纯虚拟析构函数不会产生任何不良影响。

在我看来，纯虚拟析构函数可能很有用。 例如，假设您的代码中有两个类 myClassA 和 myClassB，并且 myClassB 继承自 myClassA。 由于 Scott Meyers 在他的书“更有效的 C++”第 33 项“使非叶类抽象”中提到的原因，更好的做法是实际创建一个抽象类 myAbstractClass，myClassA 和 myClassB 从中继承。 这提供了更好的抽象并防止因对象副本等问题而出现的一些问题。

在抽象过程（创建类 myAbstractClass）中，myClassA 或 myClassB 中的任何方法都可能不是纯虚方法的良好候选者（这是 myAbstractClass 抽象的先决条件）。 在这种情况下，您将抽象类的析构函数定义为纯虚函数。

下面是我自己编写的一些代码的具体示例。 我有两个类，Numerics/PhysicsParams，它们共享共同的属性。 因此我让它们继承抽象类IParams。 在这种情况下，我手头绝对没有可以纯粹虚拟的方法。 例如，每个子类的 setParameter 方法必须具有相同的主体。 我唯一的选择就是使 IParams 的析构函数成为纯虚拟的。

struct IParams
{
    IParams(const ModelConfiguration& aModelConf);
    virtual ~IParams() = 0;

    void setParameter(const N_Configuration::Parameter& aParam);

    std::map<std::string, std::string> m_Parameters;
};

struct NumericsParams : IParams
{
    NumericsParams(const ModelConfiguration& aNumericsConf);
    virtual ~NumericsParams();

    double dt() const;
    double ti() const;
    double tf() const;
};

struct PhysicsParams : IParams
{
    PhysicsParams(const N_Configuration::ModelConfiguration& aPhysicsConf);
    virtual ~PhysicsParams();

    double g()     const; 
    double rho_i() const; 
    double rho_w() const; 
};

Answer 6

如果要停止基类的实例化而不对已实现和测试的派生类进行任何更改，则可以在基类中实现纯虚拟析构函数。

Answer 7

你正在对这些答案进行假设，所以为了清楚起见，我将尝试做出一个更简单、更实际的解释。

面向对象设计的基本关系有两个：
IS-A 和 HAS-A。 这些不是我编造的。 他们就是这么称呼的。

IS-A 指示特定对象标识为类层次结构中位于其之上的类。 如果香蕉对象是水果类的子类，那么它就是水果对象。 这意味着只要可以使用水果类，就可以使用香蕉。 但它不是反射性的。 如果需要特定类，则不能用基类替换该特定类。

has-a 表示对象是复合类的一部分，并且存在所有权关系。 这在 C++ 中意味着它是一个成员对象，因此拥有它的类有责任在销毁它自己之前处理它或移交所有权。

这两个概念在单继承语言中比在 C++ 等多继承模型中更容易实现，但规则本质上是相同的。 当类标识不明确时，例如将 Banana 类指针传递到采用 Fruit 类指针的函数中，情况就会变得复杂。

虚函数首先是一个运行时的东西。 它是多态性的一部分，因为它用于在运行的程序中调用该函数时决定运行哪个函数。

virtual 关键字是一个编译器指令，用于在类标识存在歧义时按特定顺序绑定函数。 虚函数总是在父类中（据我所知），并向编译器指示成员函数与其名称的绑定应该首先是子类函数，然后是父类函数。

Fruit 类可以有一个默认返回“NONE”的虚拟函数 color()。
Banana 类 color() 函数返回“YELLOW”或“BROWN”。

但是，如果采用 Fruit 指针的函数调用发送给它的 Banana 类上的 color() ，那么会调用哪个 color() 函数？
该函数通常会为 Fruit 对象调用 Fruit::color() 。

99% 的情况下这都不是我们想要的。
但是，如果 Fruit::color() 被声明为 virtual，则将为该对象调用 Banana:color()，因为正确的 color() 函数将在调用时绑定到 Fruit 指针。
运行时将检查指针指向哪个对象，因为它在 Fruit 类定义中被标记为虚拟。

这与重写子类中的函数不同。 在这种情况下
如果 Fruit 指针只知道它是指向 Fruit 的指针，则它会调用 Fruit::color()。

现在出现了“纯虚函数”的想法。
这是一个相当不幸的短语，因为纯洁与它无关。 这意味着永远不会调用基类方法。
确实不能调用纯虚函数。 然而，它仍然必须被定义。 函数签名必须存在。 许多编码员为了完整性而制作了一个空的实现 {}，但如果没有，编译器将在内部生成一个。 在这种情况下，当调用该函数时，即使指针指向 Fruit ，也会调用 Banana::color() ，因为它是 color() 的唯一实现。

现在拼图的最后一块：构造函数和析构函数。

纯虚拟构造函数是完全非法的。 那是刚刚出来的。

但是纯虚拟析构函数在您想要禁止创建基类实例的情况下确实有效。 如果基类的析构函数是纯虚函数，则只能实例化子类。
约定是将其分配给 0。

 virtual ~Fruit() = 0;  // pure virtual 
 Fruit::~Fruit(){}      // destructor implementation

在这种情况下，您必须创建一个实现。 编译器知道这就是您正在做的事情，并确保您做得正确，否则它会强烈抱怨它无法链接到它需要编译的所有函数。 如果您在如何建模类层次结构方面没有走上正确的道路，这些错误可能会令人困惑。

因此，在这种情况下，您被禁止创建 Fruit 实例，但允许创建 Banana 实例。

调用删除指向 Banana 实例的 Fruit 指针
总是先调用 Banana::~Banana() 然后调用 Fuit::~Fruit() 。
因为无论怎样，当你调用子类析构函数时，必须跟随基类析构函数。

这是一个糟糕的模型吗？ 是的，它在设计阶段更复杂，但它可以确保在运行时执行正确的链接，并且在访问哪个子类存在歧义的情况下执行子类函数。

如果您编写 C++ 时只传递精确的类指针，而不传递通用或模糊的指针，那么实际上并不需要虚函数。
但是，如果您需要类型的运行时灵活性（如 Apple Banana Orange ==> Fruit ），则函数会变得更简单、更通用，并且冗余代码更少。
您不再需要为每种类型的水果编写一个函数，并且您知道每种水果都会用其自己的正确函数响应 color() 。

我希望这个冗长的解释能够巩固这个概念而不是混淆事物。 有很多很好的例子可供参考，
观察足够多的内容，实际运行它们，搞乱它们，你就会得到它。

Answer 8

您要求提供一个示例，我相信以下内容提供了纯虚拟析构函数的原因。 我期待回复这是否是一个好的原因...

我不希望任何人能够抛出error_base类型，但异常类型error_oh_shucks 和 error_oh_blast 具有相同的功能，我不想写两次。 pImpl 复杂性对于避免将 std::string 暴露给我的客户端是必要的，并且使用 std::auto_ptr 需要复制构造函数。

公共标头包含异常规范，客户端可使用这些规范来区分我的库引发的不同类型的异常：

// error.h

#include <exception>
#include <memory>

class exception_string;

class error_base : public std::exception {
 public:
  error_base(const char* error_message);
  error_base(const error_base& other);
  virtual ~error_base() = 0; // Not directly usable

  virtual const char* what() const;
 private:
  std::auto_ptr<exception_string> error_message_;
};

template<class error_type>
class error : public error_base {
 public:
   error(const char* error_message) : error_base(error_message) {}
   error(const error& other) : error_base(other) {}
   ~error() {}
};

// Neither should these classes be usable
class error_oh_shucks { virtual ~error_oh_shucks() = 0; }
class error_oh_blast { virtual ~error_oh_blast() = 0; }

这是共享实现：

// error.cpp

#include "error.h"
#include "exception_string.h"

error_base::error_base(const char* error_message)
  : error_message_(new exception_string(error_message)) {}

error_base::error_base(const error_base& other)
  : error_message_(new exception_string(other.error_message_->get())) {}

error_base::~error_base() {}

const char* error_base::what() const {
  return error_message_->get();
}

保持私有的Exception_string类从我的公共接口中隐藏了std::string：

// exception_string.h

#include <string>

class exception_string {
 public:
  exception_string(const char* message) : message_(message) {}

  const char* get() const { return message_.c_str(); }
 private:
  std::string message_;
};

然后我的代码会抛出一个错误：

#include "error.h"

throw error<error_oh_shucks>("That didn't work");

The use of a template for error is a little gratuitous. 它节省了一些代码，但代价是要求客户端捕获错误，如下所示：

// client.cpp

#include <error.h>

try {
} catch (const error<error_oh_shucks>&) {
} catch (const error<error_oh_blast>&) {
}

Answer 9

也许还有另一个纯虚拟析构函数的真实用例，我实际上在其他答案中看不到:)

首先，我完全同意标记的答案：这是因为禁止纯虚拟析构函数需要语言规范中的额外规则。 但这仍然不是 Mark 所要求的用例:)

首先想象一下：

class Printable {
  virtual void print() const = 0;
  // virtual destructor should be here, but not to confuse with another problem
};

以及类似的东西：

class Printer {
  void queDocument(unique_ptr<Printable> doc);
  void printAll();
};

简单地 - 我们有接口 Printable 和一些包含此接口的任何内容的“容器”。 我认为这里很清楚为什么 print() 方法是纯虚拟的。 它可以有一些主体，但如果没有默认实现，纯虚拟是理想的“实现”（“必须由后代类提供”）。

现在想象一下完全相同的情况，只是它不是用于打印而是用于销毁：

class Destroyable {
  virtual ~Destroyable() = 0;
};

而且还可能有一个类似的容器：

class PostponedDestructor {
  // Queues an object to be destroyed later.
  void queObjectForDestruction(unique_ptr<Destroyable> obj);
  // Destroys all already queued objects.
  void destroyAll();
};

它是我的实际应用程序的简化用例。 这里唯一的区别是使用“特殊”方法（析构函数）而不是“普通”print()。 但它是纯虚拟的原因仍然是一样的——该方法没有默认代码。
有点令人困惑的是，必须有一些有效的析构函数，并且编译器实际上为其生成一个空代码。 但从程序员的角度来看，纯虚拟仍然意味着：“我没有任何默认代码，它必须由派生类提供”。

我认为这里没有什么大的想法，只是更多地解释纯虚拟性的工作原理非常一致——对于析构函数也是如此。

Answer 10

这是一个十年前的话题:)
阅读“Effective C++”一书中第 7 条的最后 5 段了解详细信息，从“偶尔为类提供纯虚拟析构函数会很方便......”开始

Answer 11

我们需要将析构函数设为虚拟，因为如果我们不将析构函数设为虚拟，那么编译器只会析构基类的内容，所有派生类将保持不变，因为编译器不会调用任何其他类的析构函数。除基类外的类。