析构函数 private 、virtual的作用

类中“私有”权限的含义就是：私有成员只能在类域内被访问，不能在类域外进行访问。   
    
把析构函数定义为私有的，就阻止了用户在类域外对析构函数的使用。这表现在如下两个方面：   
    
1.  禁止用户对此类型的变量进行定义，即禁止在栈内存空间内创建此类型的对象。要创建对象，只能用   new   在堆上进行。   
    

2.  禁止用户在程序中使用   delete   删除此类型对象。对象的删除只能在类内实现，也就是说只有类的实现者才有可能实现对对象的   delete，用户不能随便删除对象。如果用户想删除对象的话，只能按照类的实现者提供的方法进行。  

《More Effective C++》

条款27: 要求或禁止基于堆的对象
有时你想这样管理某些对象，要让某种类型的对象能够自我销毁，也就是能够“delete this”。很明显这种管理方式需要此类型对象被分配在堆中。而其它一些时候你想获得一种保障：“不在堆中分配对象，从而保证某种类型的类不会发生内存泄漏。”如果你在嵌入式系统上工作，就有可能遇到这种情况，发生在嵌入式系统上的内存泄漏是极其严重的，其堆空间是非常珍贵的。有没有可能编写出代码来要求或禁止在基于堆的对象(heap-based object)呢？通常是可以的，不过这种代码也会把“在堆中”的概念搞得比你脑海中所想的要模糊。

要求基于堆的对象
让我们先从必须在堆中建立对象开始说起。为了执行这种限制，你必须找到一种方法禁止以调用“new”以外的其它手段建立对象。这很容易做到。非堆对象(non-heap object)在定义它的地方被自动构造，在生存时间结束时自动被释放，所以只要禁止使用隐式的构造函数和析构函数，就可以实现这种限制。

把这些调用变得不合法的一种最直接的方法是把构造函数和析构函数声明为private。这样做副作用太大。没有理由让这两个函数都是private。最好让析构函数成为private，让构造函数成为public。处理过程与条款26相似，你可以引进一个专用的伪析构函数，用来访问真正的析构函数。客户端调用伪析构函数释放他们建立的对象。

析构函数virtual与非virtual区别

作为通常的原则，如果一个类定义了虚函数，那么它的析构函数就应当是virtual的。因为定义了虚函数则隐含着：这个类会被继承，并且会通过基类的指针指向子类对象，从而得到多态性。   这个类可能会被继承，并且会通过基类的指针指向子类对象”，因此基类的析构函数是否为虚将决定子类的对象是否被析构

示例代码：

#include 

struct A
{
    virtual ~A() {cout<<"~A()\n";}
};

struct B: public A
{
    ~B() {cout<<"~B()\n";}
};

void main()
{
    A* p = new B;
    delete p;
}

如果 A的析构函数不是virtual的，那么此时就不是先调用B的析构函数再调用A的析构函数。 
Output:
~A();  
如果A   的析构函数为virtual，则先~B()，再~A()   
Output:
~B();
~A();
       类如果会被派生的话，析构函数一般都应该定义为virtual的，主要不是防止内存泄露，而是为了正确的析构。如果是个封闭类（即不再被派生），就不要定义为virtual的。虚函数毕竟耗费较大的。

不用virtual 的几种情况：
  1、作为非公有基类。仅作为   private   base   class   使用的  class   不需要使用虚拟析构函数   
  2、不作为接口使用的基类。   
  3.   如果你可以保证这个类不被public继承（private/protected继承的话，在非friend函数/类中就无法用基类指针指向派生类了）   
  4.   如果它的所有派生类（包括派生类的派生类）的析构函数都是trivial的（这里的trivial指的是在程序员的层次什么事也不做）   
  5.   如果不需要用基类的指针指向派生类的对象   
  在这五种情况下，不把析构函数声明为virtual都是可以的，何况效率会高一些——但前提是你得保证前提的成立——不过这些保证常常是很难100％的：谁能保证别人在派生你的类的时候，析构函数是trivial的，或者别人不用你提供的基类的指针指向派生类对象？这些常常是很难得到保证的。  

声明基类的析构函数为virtual并非总是为了防止memory   leak   另外这也只是作为一般的原则（基类中有虚函数则把其析构函数声明为virtual）。如果你的析构函数什么事也不作，从效果上来说，不声明为virtual也无妨