有许多种做法可以记录时间，因此，设计一个TimeKeeper base class和一些derived classes 作为不同的计时方法，相当合情合理：
class TimeKeeper {
public:
TimeKeeper();
~TimeKeeper();
// ...
};
class AtomicClock: public TimeKeeper { }; // 原子钟
class WaterClock: public TimeKeeper { }; // 水钟
class WristWatch: public TimeKeeper { }; // 腕表许多客户只想在程序中使用时间，不想操心时间如何计算等细节，这时候我们可以设计factory (工厂）函数，返回指针指向一个计时对象。Factory函数会“返回一个base class 指针，指向新生成之 derived class对象”:
TimeKeeper* getTimeKeeper(); // 返回一个指针，指向一个
// TimeKeeper派生类动态分配的对象为遵守factory函数的规矩，被getTimeKeeper()返回的对象必须位于heap。因此为了避免泄漏内存和其他资源，将factory函数返回的每一个对象适当地delete掉很重要:
TimeKeeper* ptk = getTimeKeeper();
// ...
delete ptk;条款13说“倚赖客户执行delete动作，基本上便带有某种错误倾向”，条款18则谈到factory函数接口该如何修改以便预防常见之客户错误，但这些在此都是次要的，因为此条款内我们要对付的是上述代码的一个更根本弱点：纵使客户把每一件事都做对了，仍然没办法知道程序如何行动。
问题出在getTimeKeeper返回的指针指向一个derived class对象（例如AtomicClock)，而那个对象却经由一个base class指针（例如一个TimeKeeper*指针）被删除，而目前的base class ( TimeKeeper）有个non-virtual析构函数。
这是一个引来灾难的秘诀，因为C++明白指出，当derived class对象经由一个base class指针被删除,而该base class带着一个non-virtual析构函数,其结果未有定义———实际执行时通常发生的是对象的derived成分没被销毁。如果getTimeKeeper返回指针指向一个AtomicClock 对象，其内的 AtomicClock 成分（也就是声明于Atomicclock class内的成员变量）很可能没被销毁，而AtomicClock的析构函数也未能执行起来。然而其base class成分（也就是TimeKeeper这一部分）通常会被销毁，于是造成一个诡异的“局部销毁”对象。这可是形成资源泄漏、败坏之数据结构、在调试器上浪费许多时间的绝佳途径喔。
消除这个问题的做法很简单:给base class一个virtual析构函数。此后删除derive dclass对象就会如你想要的那般。是的，它会销毁整个对象，包括所有derived class成分:
class TimeKeeper {
public:
TimeKeeper();
virtual ~TimeKeeper();
// ...
};
TimeKeeper* ptk = getTimeKeeper();
// ...
delete ptk;像TimeKeeper这样的base classes除了析构函数之外通常还有其他virtual函数，因为 virtual函数的目的是允许derived class 的实现得以客制化（见条款34)。例如TimeKeeper就可能拥有一个virtual getcurrentTime，它在不同的derived classes 中有不同的实现码。任何 class只要带有 virtual函数都几乎确定应该也有一个virtual析构函数。
如果class 不含virtual函数，通常表示它并不意图被用做一个base class。当class不企图被当作 base class，令其析构函数为virtual往往是个嫂主意。考虑一个用来表示二维空间点坐标的class:
馊主意？？？
class Point {
public:
Point(int xCoord, int yCoord);
~Point();
private:
int x, y;
};如果int占用32 bits，那么Point对象可塞入一个64-bit缓存器中。更有甚者，这样一个Point对象可被当做一个“64-bit 量”传给以其他语言如C或FORTRAN撰写的函数。然而当Point的析构函数是virtual，形势起了变化。
欲实现出 virtual函数，对象必须携带某些信息，主要用来在运行期决定哪一个virtual函数该被调用。这份信息通常是由一个所谓vptr ( virtual table pointer）指针指出。 vptr指向一个由函数指针构成的数组,称为vtbl( virtual table);每一个带有 virtual函数的class 都有一个相应的vtbl。当对象调用某一virtual函数，实际被调用的函数取决于该对象的vptr所指的那个vtbl—编译器在其中寻找适当的函数指针。
多了虚函数表
virtual函数的实现细节不重要。重要的是如果Point class内含virtual函数，其对象的体积会增加:在32-bit计算机体系结构中将占用64 bits (为了存放两个ints)至96 bits（两个ints加上 vptr);在64-bit计算机体系结构中可能占用64~128 bits,因为指针在这样的计算机结构中占64 bits。因此，为 Point添加一个vptr会增加其对象大小达50%~100%，Point对象不再能够塞入一个64-bit缓存器,而C++的Point对象也不再和其他语言（如C)内的相同声明有着一样的结构（因为其他语言的对应物并没有 vptr)，因此也就不再可能把它传递至（或接受自）其他语言所写的函数，除非你明确补偿vptr—一那属于实现细节，也因此不再具有移植性。
因此，无端地将所有 classes的析构函数声明为virtual，就像从未声明它们为virtual一样，都是错误的。许多人的心得是:只有当class内含至少一个virtual函数，才为它声明virtual析构函数。
即使class完全不带virtual函数，被“non-virtual析构函数问题”给咬伤还是有可能的。举个例子，标准string不含任何virtual函数，但有时候程序员会错误地把它当做base class:
class SpecialString: public std::string {
// 馊主意。std::string有个非虚的析构函数
};乍看似乎无害，但如果你在程序任意某处无意间将一个pointer-to-SpecialString转换为一个pointer-to-string，然后将转换所得的那个string 指针 delete掉，你立刻被流放到“行为不明确”的恶地上:
将子类指针转换成父类指针，让后delete掉
Specialstring* pss = new Specialstring ("Impending Doom");
std::string* ps;
ps = pss; // Specialstring* =》 std::string*
delete ps;
//未有定义!现实中*ps的 Specialstring资源会泄漏，
//因为SpecialString析构函数没被调用。
相同的分析适用于任何不带virtual析构函数的 class，包括所有STL容器如vector, list,set, tr1 : : unordered_map（见条款54）等等。如果你曾经企图继承一个标准容器或任何其他“带有non-virtual析构函数”的class，拒绝诱惑吧!(很不幸C+没有提供类似Java的final classes或C#的sealed classes那样的“禁止派生”机制。)
有时候令class带一个pure virtual析构函数,可能颇为便利。还记得吗, pure virtual函数导致abstract（抽象）classes -—也就是不能被实体化(instantiated）的class。也就是说，你不能为那种类型创建对象。然而有时候你希望拥有抽象class，但手上没有任何pure virtual函数,怎么办?唔,由于抽象class总是企图被当作一个base class来用，而又由于base class应该有个virtual析构函数，并且由于pure virtual函数会导致抽象class,因此解法很简单:为你希望它成为抽象的那个class声明一个pure virtual析构函数。下面是个例子:
class AWOV {
public:
virtual ~AWOV() = 0; // 纯析构函数
};这个class有一个pure virtual函数，所以它是个抽象class，又由于它有个virtual析构函数，所以你不需要担心析构函数的问题。然而这里有个窍门:你必须为这个pure virtual析构函数提供一份定义:
AwOV:: ~AWOV() { } //pure virtual析构函数的定
第一次知道要这样。
析构函数的运作方式是，最深层派生( most derived）的那个class其析构函数最先被调用,然后是其每一个base class的析构函数被调用。编译器会在 AWov的derivedclasses的析构函数中创建一个对~AWOV的调用动作，所以你必须为这个函数提供一份定义。如果不这样做，连接器会发出抱怨。
“给base classes一个 virtual析构函数”，这个规则只适用于polymorphic(带多态性质的)base classes身上。这种base classes的设计目的是为了用来“通过base class接口处理derived class对象”。TimeKeeper就是一个polymorphic base class，因为我们希望处理AtomicClock和 waterClock对象,纵使我们只有TimeKeeper 指针指向它们。
并非所有base classes的设计目的都是为了多态用途。例如标准string和STL容器都不被设计作为base classes使用，更别提多态了。某些classes的设计目的是作为base classes 使用，但不是为了多态用途。这样的classes 如条款6的Uncopyable和标准程序库的input_iterator_tag(条款47)，它们并非被设计用来“经由baseclass接口处置derived class对象”，因此它们不需要virtual析构函数。文章来源：https://www.toymoban.com/news/detail-656310.html
请记住文章来源地址https://www.toymoban.com/news/detail-656310.html
- polymorphic（带多态性质的）base classes应该声明一个virtual析构函数。如果class带有任何 virtual函数，它就应该拥有一个virtual析构函数。
- Classes的设计目的如果不是作为base classes使用，或不是为了具备多态性(polymorphically)，就不该声明virtual析构函数
到了这里，关于Effective C++条款07——为多态基类声明virtual析构函数（构造/析构/赋值运算）的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
