blocks|key|3311385|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3311386|可能允许纯虚拟析构函数的真正原因是，禁止它们将意味着向语言中添加另一个规则，并且没有必要使用此规则，因为允许纯虚拟析构函数不会产生任何不良影响。|ordered-list-item|3311387|3311388|如果您使用其虚方法的默认实现创建了一个对象，并且希望使其成为抽象对象而不强制任何人覆盖任何特定于的方法，则可以将析构函数设为纯虚的。我看不出这有多大意义，但这是可能的。|offset|length|style|BOLD|3311389|请注意，由于编译器将为派生类生成隐式析构函数，因此如果类的作者不这样做，任何派生类都将不是抽象的()。因此，在基类中使用纯虚拟析构函数不会对派生类产生任何影响。它只会让基类变得抽象(感谢@kappa的评论)。|3311390|还可以假设每个派生类都可能需要特定的清理代码，并使用纯虚拟析构函数作为提醒来编写一个，但这似乎是人为的(且未强制执行)。|3311391|注意:析构函数是唯一的方法，即使它是纯虚函数，也有实现以实例化派生类(是的，纯虚函数也可以有实现)。|3311392|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.
};|code-block|syntax|javascript|3311393|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/users/771271/kappa^0|0|0|0|1C|1|0|2L|6|0|0|0|0|7|N|2|0|0^^$0|@$1|2|3|-4|4|5|6|13|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|14|7|@]|8|@]|9|$]]|$1|D|3|-4|4|5|6|15|7|@]|8|@]|9|$]]|$1|E|3|F|4|5|6|16|7|@$G|17|H|18|I|J]]|8|@]|9|$]]|$1|K|3|L|4|5|6|19|7|@]|8|@$G|1A|H|1B|1|1C]]|9|$]]|$1|M|3|N|4|5|6|1D|7|@]|8|@]|9|$]]|$1|O|3|P|4|5|6|1E|7|@$G|1F|H|1G|I|J]|$G|1H|H|1I|I|J]]|8|@]|9|$]]|$1|Q|3|R|4|S|6|1J|7|@]|8|@]|9|$T|U]]|$1|V|3|-4|4|5|6|1K|7|@]|8|@]|9|$]]]|W|$X|$4|Y|Z|10|9|$11|12]]]]

<ol>
<li>Probably the real reason that pure virtual destructors are allowed is that to prohibit them would mean adding another rule to the language and there's no need for this rule since no ill-effects can come from allowing a pure virtual destructor.</li>
<li>Nope, plain old virtual is enough. </li>
</ol>

If you create an object with default implementations for its virtual methods and want to make it abstract without forcing anyone to override any specific method, you can make the destructor pure virtual. I don't see much point in it but it's possible. 

Note that since the compiler will generate an implicit destructor for derived classes, if the class's author does not do so, any derived classes will not be abstract. Therefore having the pure virtual destructor in the base class will not make any difference for the derived classes. It will only make the base class abstract (thanks for <a href="https://stackoverflow.com/users/771271/kappa">@kappa</a>'s comment).

One may also assume that every deriving class would probably need to have specific clean-up code and use the pure virtual destructor as a reminder to write one but this seems contrived (and unenforced).

Note: The destructor is the only method that even if it is pure virtual has to have an implementation in order to instantiate derived classes (yes pure virtual functions can have implementations).

<pre><code>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.
};
</code></pre>

blocks|key|332834|text|如果要创建抽象基类：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|332835|虚析构函数不能被实例化(是的，这与术语"abstract"!)|332836|but需要虚析构函数行为是多余的(您打算携带指向ABC的指针，而不是指向派生类型的指针，并通过它们删除)|unordered-list-item|332837|但不需要其他方法的任何其他虚拟分派<>E211>行为(可能没有其他方法？考虑一个简单的受保护的“资源”容器，它需要一个构造函数/析构函数/赋值函数，但不需要太多其他东西)|offset|length|style|BOLD|332838|332839|332840|...通过使析构函数成为纯虚的并为其提供定义(方法体)来使类成为抽象的类是最容易的。|332841|对于我们假设的ABC：|332842|你保证它不能被实例化(甚至在类本身的内部，这就是私有构造函数可能不够的原因)，你得到了你想要的析构函数的虚拟行为，并且你不必找到另一个不需要虚拟分派的方法并将其标记为“虚拟”。|332843|entityMap^0|0|0|0|1|2C|0|0|0|0|16|0|0|B|0|0|2G|0^^$0|@$1|2|3|4|5|6|7|W|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|X|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|Y|8|@]|9|@]|A|$]]|$1|G|3|H|5|F|7|Z|8|@$I|10|J|11|K|L]]|9|@]|A|$]]|$1|M|3|-4|5|6|7|12|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|13|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|14|8|@$I|15|J|16|K|L]]|9|@]|A|$]]|$1|Q|3|R|5|6|7|17|8|@$I|18|J|19|K|L]]|9|@]|A|$]]|$1|S|3|T|5|6|7|1A|8|@$I|1B|J|1C|K|L]]|9|@]|A|$]]|$1|U|3|-4|5|6|7|1D|8|@]|9|@]|A|$]]]|V|$]]

If you want to create an abstract base class:

<ul>
<li>that can't be instantiated (yep, this is redundant with the term "abstract"!)</li>
<li>but needs virtual destructor behavior (you intend to carry around pointers to the ABC rather than pointers to the derived types, and delete through them)</li>
<li>but does not need any other virtual dispatch behavior for other methods (maybe there are no other methods? consider a simple protected "resource" container that needs a constructors/destructor/assignment but not much else)</li>
</ul>

...it's easiest to make the class abstract by making the destructor pure virtual and providing a definition (method body) for it.

For our hypothetical ABC:

You guarantee that it cannot be instantiated (even internal to the class itself, this is why private constructors may not be enough), you get the virtual behavior you want for the destructor, and you do not have to find and tag another method that doesn't need virtual dispatch as "virtual".

blocks|key|3311455|text|抽象类所需要的就是至少一个纯虚函数。任何函数都可以；但是碰巧的是，析构函数是任何类都会有的东西--所以它总是作为候选函数存在。此外，将析构函数设为纯虚的(而不仅仅是虚的)除了使类抽象之外，没有任何行为上的副作用。因此，许多风格指南建议一致地使用纯虚拟destuctor来指示类是抽象的-如果没有其他原因，只是因为它提供了一个一致的位置，阅读代码的人可以查看类是否是抽象的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3311456|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

All you need for an abstract class is at least one pure virtual function. Any function will do; but as it happens, the destructor is something that any class will have&mdash;so it's always there as a candidate. Furthermore, making the destructor pure virtual (as opposed to just virtual) has no behavioral side effects other than to make the class abstract. As such, a lot of style guides recommend that the pure virtual destuctor be used consistently to indicate that a class is abstract&mdash;if for no other reason than it provides a consistent place someone reading the code can look to see if the class is abstract.

blocks|key|337765|text|如果您想停止实例化基类而不对已实现和测试的派生类进行任何更改，您可以在基类中实现一个纯虚拟析构函数。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|337766|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If you want to stop instantiating of base class without making any change in your already implemented and tested derive class, you implement a pure virtual destructor in your base class.

blocks|key|334432|text|我们需要使析构函数虚化，因为如果我们不使析构函数虚化，那么编译器只会析构基类的内容，n所有的派生类将保持不变，因为使用编译器不会调用基类以外的任何其他类的析构函数。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|334433|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

we need to make destructor virtual bacause of the fact that , if we dont make the destructor virtual then compiler will only destruct the contents of base class , n all the derived classes will remain un changed , bacuse compiler will not call the destructor of any other class except the base class.

blocks|key|3098628|text|您要求提供一个示例，我相信下面的内容提供了一个使用纯虚拟析构函数的理由。我期待着回复这是否是一个好的理由……|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3098629|我不希望任何人都能抛出error_base类型，但是异常类型error_oh_shucks和error_oh_blast具有相同的功能，我不想重复编写它。为了避免将std::string暴露给我的客户机，pImpl的复杂性是必要的，而使用std::auto_ptr则必须使用复制构造函数。|offset|length|style|CODE|3098630|public标头包含异常规范，客户端可以使用这些规范来区分我的库抛出的不同类型的异常：|3098631|//+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;+}|code-block|syntax|javascript|3098632|下面是共享的实现：|3098633|//+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();
}|3098634|保持私有的exception_string类对我的公共接口隐藏了std::string：|3098635|//+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_;
};|3098636|然后我的代码抛出一个错误，如下所示：|3098637|#include+"error.h"

throw+error<error_oh_shucks>("That+didn't+work");|3098638|使用error的模板是不必要的。它节省了一些代码，但要求客户端捕获错误，如下所示：|3098639|//+client.cpp

#include+<error.h>

try+{
}+catch+(const+error<error_oh_shucks>&)+{
}+catch+(const+error<error_oh_blast>&)+{
}|3098640|entityMap^0|0|B|A|U|F|1A|E|2A|B|3B|D|0|0|0|0|0|0|0|0|0|2|5|0|0^^$0|@$1|2|3|4|5|6|7|16|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|17|8|@$D|18|E|19|F|G]|$D|1A|E|1B|F|G]|$D|1C|E|1D|F|G]|$D|1E|E|1F|F|G]|$D|1G|E|1H|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|1I|8|@]|9|@]|A|$]]|$1|J|3|K|5|L|7|1J|8|@]|9|@]|A|$M|N]]|$1|O|3|P|5|6|7|1K|8|@]|9|@]|A|$]]|$1|Q|3|R|5|L|7|1L|8|@]|9|@]|A|$M|N]]|$1|S|3|T|5|6|7|1M|8|@]|9|@]|A|$]]|$1|U|3|V|5|L|7|1N|8|@]|9|@]|A|$M|N]]|$1|W|3|X|5|6|7|1O|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|L|7|1P|8|@]|9|@]|A|$M|N]]|$1|10|3|11|5|6|7|1Q|8|@$D|1R|E|1S|F|G]]|9|@]|A|$]]|$1|12|3|13|5|L|7|1T|8|@]|9|@]|A|$M|N]]|$1|14|3|-4|5|6|7|1U|8|@]|9|@]|A|$]]]|15|$]]

You asked for an example, and I believe the following provides a reason for a pure virtual destructor. I look forward to replies as to whether this is a good reason...

I do not want anyone to be able to throw the <code>error_base</code> type, but the exception types <code>error_oh_shucks</code> and <code>error_oh_blast</code> have identical functionality and I don't want to write it twice. The pImpl complexity is necessary to avoid exposing <code>std::string</code> to my clients, and the use of <code>std::auto_ptr</code> necessitates the copy constructor.

The public header contains the exception specifications that will be available to the client to distinguish different types of exception being thrown by my library:

<pre><code>// error.h

#include &lt;exception&gt;
#include &lt;memory&gt;

class exception_string;

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

 virtual const char* what() const;
 private:
 std::auto_ptr&lt;exception_string&gt; error_message_;
};

template&lt;class error_type&gt;
class error : public error_base {
 public:
 error(const char* error_message) : error_base(error_message) {}
 error(const error&amp; 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; }
</code></pre>

And here is the shared implementation:

<pre><code>// 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&amp; other)
 : error_message_(new exception_string(other.error_message_-&gt;get())) {}

error_base::~error_base() {}

const char* error_base::what() const {
 return error_message_-&gt;get();
}
</code></pre>

The exception_string class, kept private, hides std::string from my public interface:

<pre><code>// exception_string.h

#include &lt;string&gt;

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

 const char* get() const { return message_.c_str(); }
 private:
 std::string message_;
};
</code></pre>

My code then throws an error as:

<pre><code>#include "error.h"

throw error&lt;error_oh_shucks&gt;("That didn't work");
</code></pre>

The use of a template for <code>error</code> is a little gratuitous. It saves a bit of code at the expense of requiring clients to catch errors as:

<pre><code>// client.cpp

#include &lt;error.h&gt;

try {
} catch (const error&lt;error_oh_shucks&gt;&amp;) {
} catch (const error&lt;error_oh_blast&gt;&amp;) {
}
</code></pre>

blocks|key|337796|text|在这里，我想告诉大家什么时候需要虚拟析构函数，什么时候需要纯虚拟析构函数|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|337797|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
}|code-block|syntax|javascript|337798|337799|当你希望没有人能够直接创建基类的对象时，可以使用纯虚拟析构函数virtual+~Base()+=+0。通常-至少需要一个纯虚函数，让我们以virtual+~Base()+=+0为例，因为这个虚函数你不需要上面的东西，只需要安全地销毁派生类对象|ordered-list-item|CODE|337800|337801|*+pBase+=新派生的()；删除析构函数；不需要纯虚拟析构函数，只需要虚拟析构函数即可。|337802|entityMap^0|G|6|T|7|0|0|0|V|J|1X|J|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]|$9|X|A|Y|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|Z|8|@]|D|@]|E|$I|J]]|$1|K|3|-4|5|6|7|10|8|@]|D|@]|E|$]]|$1|L|3|M|5|N|7|11|8|@$9|12|A|13|B|O]|$9|14|A|15|B|O]]|D|@]|E|$]]|$1|P|3|-4|5|6|7|16|8|@]|D|@]|E|$]]|$1|Q|3|R|5|6|7|17|8|@]|D|@]|E|$]]|$1|S|3|-4|5|6|7|18|8|@]|D|@]|E|$]]]|T|$]]

Here I want to tell when we need virtual destructor and when we need pure virtual destructor

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

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


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

Derived::Derived() { cout &lt;&lt; "Derived Constructor" &lt;&lt; endl; }
Derived::~Derived() { cout &lt;&lt; "Derived Destructor" &lt;&lt; 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
}
</code></pre>

<ol>
<li>When you want that no one should be able to create the object of Base class directly, use pure virtual destructor <code>virtual ~Base() = 0</code>. Usually at-least one pure virtual function is required, let's take <code>virtual ~Base() = 0</code>, as this function.</li>
<li>When you do not need above thing, only you need the safe destruction of Derived class object 

Base* pBase = new Derived();
delete pBase;
pure virtual destructor is not required, only virtual destructor will do the job.</li>
</ol>

blocks|key|3311589|text|从我对你的问题的回答中，我不能推断出一个真正使用纯虚拟析构函数的好理由。例如，以下原因根本不能说服我：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3311590|3311591|可能允许纯虚拟析构函数的真正原因是，禁止它们将意味着向语言中添加另一个规则，并且没有必要使用此规则，因为允许纯虚拟析构函数不会产生任何不良影响。|blockquote|3311592|3311593|3311594|在我看来，纯虚拟析构函数是有用的。例如，假设您的代码中有两个类myClassA和myClassB，并且myClassB继承自myClassA。由于Scott+Meyer在他的书“更有效的C%2B%2B"，项目33”使非叶类抽象“中提到的原因，更好的做法是实际创建myClassA和myClassB继承的抽象类myAbstractClass。这提供了更好的抽象，并防止了一些问题，例如，对象副本。|3311595|在抽象过程(创建类myAbstractClass)中，myClassA或myClassB的任何方法都不是成为纯虚方法的好候选者(这是myAbstractClass成为抽象方法的先决条件)。在本例中，您将抽象类的析构函数定义为纯虚拟的。|3311596|下面是我自己编写的一些代码中的一个具体示例。我有两个类，Numerics/PhysicsParams，它们共享共同的属性。因此，我让它们继承自抽象类IParams。在这种情况下，我手头绝对没有纯虚拟的方法。例如，对于每个子类，setParameter方法必须具有相同的主体。我唯一的选择就是将IParams的析构函数设为纯虚拟的。|3311597|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;+
};|code-block|syntax|javascript|3311598|entityMap^0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|U|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|V|8|@]|9|@]|A|$]]|$1|C|3|D|5|E|7|W|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|A|$]]|$1|G|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|Z|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|10|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|11|8|@]|9|@]|A|$]]|$1|N|3|O|5|P|7|12|8|@]|9|@]|A|$Q|R]]|$1|S|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|T|$]]

From the answers I have read to your question, I couldn't deduce a good reason to actually use a pure virtual destructor. For example, the following reason doesn't convince me at all:

<blockquote>
 Probably the real reason that pure virtual destructors are allowed is that to prohibit them would mean adding another rule to the language and there's no need for this rule since no ill-effects can come from allowing a pure virtual destructor.
</blockquote>

In my opinion, pure virtual destructors can be useful. For example, assume you have two classes myClassA and myClassB in your code, and that myClassB inherits from myClassA. For the reasons mentioned by Scott Meyers in his book "More Effective C++", Item 33 "Making non-leaf classes abstract", it is better practice to actually create an abstract class myAbstractClass from which myClassA and myClassB inherit. This provides better abstraction and prevents some problems arising with, for example, object copies.

In the abstraction process (of creating class myAbstractClass), it can be that no method of myClassA or myClassB is a good candidate for being a pure virtual method (which is a prerequisite for myAbstractClass to be abstract). In this case, you define the abstract class's destructor pure virtual. 

Hereafter a concrete example from some code I have myself written. I have two classes, Numerics/PhysicsParams which share common properties. I therefore let them inherit from the abstract class IParams. In this case, I had absolutely no method at hand that could be purely virtual. The setParameter method, for example, must have the same body for every subclass. The only choice that I have had was to make IParams' destructor pure virtual.

<pre><code>struct IParams
{
 IParams(const ModelConfiguration&amp; aModelConf);
 virtual ~IParams() = 0;

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

 std::map&lt;std::string, std::string&gt; m_Parameters;
};

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

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

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

 double g() const; 
 double rho_i() const; 
 double rho_w() const; 
};
</code></pre>

blocks|key|3311672|text|由于这些答案，您正在进入假设，所以为了清楚起见，我将尝试做出一个更简单、更脚踏实地的解释。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3311673|面向对象设计的基本关系有两种:+IS-A和HAS-A。这些都不是我编的。他们就是这么叫的。|3311674|IS-A表示特定对象标识为类层次结构中位于其上的类的成员。如果香蕉对象是水果类的子类，那么它就是水果对象。这意味着在任何可以使用水果类的地方，都可以使用香蕉。然而，它不是反身性的。如果调用特定类，则不能用基类替换该特定类。|3311675|Has-a表示对象是复合类的一部分，并且存在所有权关系。在C%2B%2B中，这意味着它是一个成员对象，因此拥有它的类有责任在销毁它之前处理它或移交所有权。|3311676|这两个概念在单继承语言中比在多继承模型(如c%2B%2B+)中更容易实现，但规则在本质上是相同的。当类标识不明确时，例如将一个Banana类指针传递到一个接受Fruit类指针的函数中，就会变得复杂。|3311677|首先，虚函数是一个运行时的东西。它是多态性的一部分，因为它用于确定在运行的程序中调用哪个函数时要运行哪个函数。|3311678|virtual关键字是一个编译器指令，用于在类标识不明确时以特定顺序绑定函数。虚函数总是在父类中(据我所知)，并向编译器表明，成员函数与其名称的绑定应该首先使用子类函数，然后使用父类函数。|3311679|Fruit类可以有一个默认返回"NONE“的虚函数color()。Banana类color()函数返回“黄色”或“棕色”。|3311680|但是，如果接受Fruit指针的函数在发送给它的Banana类上调用color()，那么会调用哪个color()函数？该函数通常会为Fruit对象调用Fruit::color()。|3311681|这在99%25的情况下都不是我们想要的。但是如果Fruit::color()被声明为virtual，那么将为对象调用Banana:color()，因为正确的color()函数将在调用时绑定到Fruit指针。运行时将检查指针所指向的对象，因为它在Fruit类定义中被标记为虚拟的。|3311682|这与重写子类中的函数不同。在这种情况下，如果Fruit指针只知道它是一个指向Fruit的指针，那么它将调用Fruit::color()。|3311683|因此，现在出现了“纯虚拟函数”的概念。这是一个相当不幸的短语，因为纯洁与它无关。这意味着它的意图是永远不调用基类方法。实际上，纯虚函数不能被调用。然而，它仍然必须被定义。函数签名必须存在。许多程序员为了完整性而创建了一个空的实现{}，但如果不是这样，编译器将在内部生成一个。在这种情况下，当调用函数时，即使指针指向Fruit，也会调用Banana::color()，因为它是color()的唯一实现。|3311684|现在是拼图的最后一块:构造函数和析构函数。|3311685|纯虚拟构造函数是完全非法的。这只是一种外泄。|3311686|但是，如果您希望禁止创建基类实例，则纯虚拟析构函数确实可以工作。如果基类的析构函数是纯虚的，则只能实例化子类。约定是将其赋值为0。|3311687|+virtual+~Fruit()+=+0;++//+pure+virtual+
+Fruit::~Fruit(){}++++++//+destructor+implementation|code-block|syntax|javascript|3311688|在这种情况下，您必须创建一个实现。编译器知道你在做什么，并确保你做得正确，否则它会强烈地抱怨它不能链接到它需要编译的所有函数。如果您没有在正确的轨道上建模您的类层次结构，那么这些错误可能会令人困惑。|3311689|因此，在这种情况下，您不能创建Fruit实例，但可以创建Banana实例。|3311690|删除指向Banana实例的Fruit指针的调用将首先调用Banana::~Banana()，然后始终调用Fuit::~Fruit()。因为不管怎样，当你调用一个子类析构函数时，基类析构函数必须跟在后面。|3311691|它是一个糟糕的模型吗？是的，它在设计阶段比较复杂，但它可以确保在运行时执行正确的链接，并确保在不明确正在访问哪个子类的情况下执行子类函数。|3311692|如果编写C%2B%2B时只传递精确的类指针，而不传递泛型或歧义指针，那么实际上就不需要虚函数了。但是，如果您需要运行时灵活的类型(如Apple、Banana、Orange、==>、Fruit+)，函数将变得更简单、更通用，而且冗余代码更少。您不再需要为每种水果编写一个函数，而且您知道每个水果都会使用自己的正确函数对color()作出响应。|3311693|我希望这个冗长的解释巩固了这个概念，而不是混淆了事情。有很多很好的例子可以看，看够了，实际运行它们，弄乱它们，你就会得到它。|3311694|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1N|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1O|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1P|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|1Q|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|1R|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|1S|8|@]|9|@]|A|$]]|$1|N|3|O|5|6|7|1T|8|@]|9|@]|A|$]]|$1|P|3|Q|5|6|7|1U|8|@]|9|@]|A|$]]|$1|R|3|S|5|6|7|1V|8|@]|9|@]|A|$]]|$1|T|3|U|5|6|7|1W|8|@]|9|@]|A|$]]|$1|V|3|W|5|6|7|1X|8|@]|9|@]|A|$]]|$1|X|3|Y|5|6|7|1Y|8|@]|9|@]|A|$]]|$1|Z|3|10|5|6|7|1Z|8|@]|9|@]|A|$]]|$1|11|3|12|5|6|7|20|8|@]|9|@]|A|$]]|$1|13|3|14|5|15|7|21|8|@]|9|@]|A|$16|17]]|$1|18|3|19|5|6|7|22|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|23|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|24|8|@]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|25|8|@]|9|@]|A|$]]|$1|1G|3|1H|5|6|7|26|8|@]|9|@]|A|$]]|$1|1I|3|1J|5|6|7|27|8|@]|9|@]|A|$]]|$1|1K|3|-4|5|6|7|28|8|@]|9|@]|A|$]]]|1L|$]]

You are getting into hypotheticals with these answers, so I will try to make a simpler, more down to earth explanation for clarity's sake.

The basic relationships of object oriented design are two:
 IS-A and HAS-A. I did not make those up. That is what they are called.

IS-A indicates that a particular object identifies as being of the class that is above it in a class hierarchy. A banana object is a fruit object if it is a subclass of the fruit class. This means that anywhere a fruit class can be used, a banana can be used. It is not reflexive , though. You can not substitute a base class for a specific class if that specific class is called for.

Has-a indicated that an object is part of a composite class and that there is an ownership relationship. It means in C++ that it is a member object and as such the onus is on the owning class to dispose of it or hand ownership off before destructing itself.

These two concepts are easier to realize in single-inheritance languages than in a multiple inheritance model like c++, but the rules are essentially the same. The complication comes when the class identity is ambiguous, such as passing a Banana class pointer into a function that takes a Fruit class pointer. 

Virtual functions are, firstly, a run-time thing. It is part of polymorphism in that it is used to decide which function to run at the time it is called in the running program. 

The virtual keyword is a compiler directive to bind functions in a certain order if there is ambiguity about the class identity. Virtual functions are always in parent classes (as far as I know) and indicate to the compiler that binding of member functions to their names should take place with the subclass function first and the parent class function after.

A Fruit class could have a virtual function color() that returns "NONE" by default.
The Banana class color() function returns "YELLOW" or "BROWN".

But if the function taking a Fruit pointer calls color() on the Banana class sent to it -- which color() function gets invoked? 
The function would normally call Fruit::color() for a Fruit object.

That would 99% of the time not be what was intended. 
But if Fruit::color() was declared virtual then Banana:color() would be called for the object because the correct color() function would be bound to the Fruit pointer at the time of the call. 
The runtime will check what object the pointer points to because it was marked virtual in the Fruit class definition.

This is different than overriding a function in a subclass. In that case
the Fruit pointer will call Fruit::color() if all it knows is that it IS-A pointer to Fruit. 

So now to the idea of a "pure virtual function" comes up.
It is a rather unfortunate phrase as purity has nothing to do with it. It means that it is intended that the base class method is never to be called.
Indeed a pure virtual function can not be called. It must still be defined, however. A function signature must exist. Many coders make an empty implementation {} for completeness, but the compiler will generate one internally if not. In that case when the function is called even if the pointer is to Fruit , Banana::color() will be called as it is the only implementation of color() there is.

Now the final piece of the puzzle: constructors and destructors.

Pure virtual constructors are illegal, completely. That is just out.

But pure virtual destructors do work in the case that you want to forbid the creation of a base class instance. Only sub classes can be instantiated if the destructor of the base class is pure virtual.
the convention is to assign it to 0.

<pre><code> virtual ~Fruit() = 0; // pure virtual 
 Fruit::~Fruit(){} // destructor implementation
</code></pre>

You do have to create an implementation in this case. The compiler knows this is what you are doing and makes sure you do it right, or it complains mightily that it can not link to all the functions it needs to compile. The errors can be confusing if you are not on the right track as to how you are modeling your class hierarchy. 

So you are forbidden in this case to create instances of Fruit, but allowed to create instances of Banana.

A call to delete of the Fruit pointer that points to an instance of Banana
will call Banana::~Banana() first and then call Fuit::~Fruit(), always.
Because no matter what, when you call a subclass destructor, the base class destructor must follow.

Is it a bad model? It is more complicated in the design phase, yes, but it can ensure that correct linking is performed at run-time and that a subclass function is performed where there is ambiguity as to exactly which subclass is being accessed. 

If you write C++ so that you only pass around exact class pointers with no generic nor ambiguous pointers, then virtual functions are not really needed. 
But if you require run-time flexibility of types (as in Apple Banana Orange ==> Fruit ) functions become easier and more versatile with less redundant code.
You no longer have to write a function for each type of fruit, and you know that every fruit will respond to color() with its own correct function.

I hope this long-winded explanation solidifies the concept rather than confuses things. There are a lot of good examples out there to look at,
and look at enough and actually run them and mess with them and you will get it.

blocks|key|332979|text|也许还有另一个纯虚拟析构函数的真实用例，实际上我在其他答案中看不到:)|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|332980|首先，我完全同意被标记的答案:这是因为禁止纯虚拟析构函数需要在语言规范中添加额外的规则。但这仍然不是Mark所要求的用例:)|332981|首先想像一下：|332982|class+Printable+{
++virtual+void+print()+const+=+0;
++//+virtual+destructor+should+be+here,+but+not+to+confuse+with+another+problem
};|code-block|syntax|javascript|332983|像这样的东西：|332984|class+Printer+{
++void+queDocument(unique_ptr<Printable>+doc);
++void+printAll();
};|332985|很简单--我们有接口Printable和一些“容器”来保存这个接口的任何东西。我认为这里很清楚为什么print()方法是纯虚拟的。它可以有一些主体，但在没有默认实现的情况下，纯虚拟是一个理想的“实现”(=“必须由后代类提供”)。|CODE|332986|现在想象一下完全一样，除了它不是用来打印的，而是用来销毁的：|332987|class+Destroyable+{
++virtual+~Destroyable()+=+0;
};|332988|也可能有一个类似的容器：|332989|class+PostponedDestructor+{
++//+Queues+an+object+to+be+destroyed+later.
++void+queObjectForDestruction(unique_ptr<Destroyable>+obj);
++//+Destroys+all+already+queued+objects.
++void+destroyAll();
};|332990|这是我实际应用程序中的简化用例。这里唯一的区别是使用了“特殊”方法(析构函数)而不是“普通”print()。但它是纯虚拟的原因仍然是一样的-该方法没有默认代码。有一点令人困惑的是，必须有一些有效的析构函数，而编译器实际上为它生成了一个空代码。但从程序员的角度来看，纯虚拟化仍然意味着：“我没有任何默认代码，它必须由派生类提供。”|332991|我认为这不是什么大的想法，只是更多的解释，纯虚拟工作真的很统一-也适用于析构函数。|332992|entityMap^0|F|4|0|0|0|0|0|0|A|9|1E|7|0|0|0|0|0|1A|7|0|0^^$0|@$1|2|3|4|5|6|7|19|8|@$9|1A|A|1B|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1C|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|1D|8|@]|D|@]|E|$]]|$1|J|3|K|5|L|7|1E|8|@]|D|@]|E|$M|N]]|$1|O|3|P|5|6|7|1F|8|@]|D|@]|E|$]]|$1|Q|3|R|5|L|7|1G|8|@]|D|@]|E|$M|N]]|$1|S|3|T|5|6|7|1H|8|@$9|1I|A|1J|B|U]|$9|1K|A|1L|B|U]]|D|@]|E|$]]|$1|V|3|W|5|6|7|1M|8|@]|D|@]|E|$]]|$1|X|3|Y|5|L|7|1N|8|@]|D|@]|E|$M|N]]|$1|Z|3|10|5|6|7|1O|8|@]|D|@]|E|$]]|$1|11|3|12|5|L|7|1P|8|@]|D|@]|E|$M|N]]|$1|13|3|14|5|6|7|1Q|8|@$9|1R|A|1S|B|U]]|D|@]|E|$]]|$1|15|3|16|5|6|7|1T|8|@]|D|@]|E|$]]|$1|17|3|-4|5|6|7|1U|8|@]|D|@]|E|$]]]|18|$]]

Maybe there is another REAL USE-CASE of pure virtual destructor which I actually can't see in other answers :)

At first, I completely agree with marked answer: It is because forbidding pure virtual destructor would need an extra rule in language specification. But it's still not the use case that Mark is calling for :)

First imagine this:

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

and something like:

<pre><code>class Printer {
 void queDocument(unique_ptr&lt;Printable&gt; doc);
 void printAll();
};
</code></pre>

Simply - we have interface <code>Printable</code> and some "container" holding anything with this interface. I think here it is quite clear why <code>print()</code> method is pure virtual. It could have some body but in case there is no default implementation, pure virtual is an ideal "implementation" (="must be provided by a descendant class").

And now imagine exactly the same except it is not for printing but for destruction:

<pre><code>class Destroyable {
 virtual ~Destroyable() = 0;
};
</code></pre>

And also there could be a similar container:

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

It's simplified use-case from my real application. The only difference here is that "special" method (destructor) was used instead of "normal" <code>print()</code>. But the reason why it is pure virtual is still the same - there is no default code for the method.
A bit confusing could be the fact that there MUST be some destructor effectively and compiler actually generates an empty code for it. But from the perspective of a programmer pure virtuality still means: "I don't have any default code, it must be provided by derived classes."

I think it's no any big idea here, just more explanation that pure virtuality works really uniformly - also for destructors.

blocks|key|3098906|text|这是一个十年前的话题:)有关详细信息，请阅读"Effective+C%2B%2B“一书中项目#7的最后5段，从”偶尔给一个类一个纯虚拟析构函数是很方便的……“开始。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3098907|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

This is a decade old topic :) 
Read last 5 paragraphs of Item #7 on "Effective C++" book for details, starts from "Occasionally it can be convenient to give a class a pure virtual destructor...."

I understand the need for a virtual destructor. But why do we need a pure virtual destructor? In one of the C++ articles, the author has mentioned that we use pure virtual destructor when we want to make a class abstract.
But we can make a class abstract by making any of the member functions as pure virtual.
So my questions are
<ol>
<li>When do we really make a destructor pure virtual? Can anybody give a good real time example?
</li>
<li>When we are creating abstract classes is it a good practice to make the destructor also pure virtual? If yes..then why?
</li>
</ol>

Why do we need a pure virtual destructor in C++?

虚拟化

编译器

容器

我理解使用虚拟析构函数的必要性。但是为什么我们需要一个纯的虚拟析构函数呢？在C++的一篇文章中，作者提到，当我们想要使类抽象时，我们使用纯虚拟析构函数。但是我们可以通过将任何成员函数作为纯虚函数来使类成为抽象的。所以我的问题是，我们什么时候才能真正让析构函数成为纯虚的呢？有人能给出一个好的实时例子吗？当我们创建抽象类时...

问为什么我们在C++中需要一个纯虚拟析构函数？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么我们在C++中需要一个纯虚拟析构函数？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么我们在C++中需要一个纯虚拟析构函数？
EN