网站首页 > 技术文章 正文
有许多种做法可以记录时间,因此,设计一个TimeKeeper base class 和一些derived classes作为不同的计时方法,相当合情合理:
class TimeKeeper {
public:
TimeKeeper();
~TimeKeeper();
....
};
class AtomicClock: public TimeKeeper { ... };//原子钟
class WaterClock: public TimeKeeper(...};//水钟
class WristWatch: publicTimeKeeper(...};//腕表
许多客户只想在程序中使用时间,不想操心时间如何计算等细节,这时候我们可以设计factory(工厂)函数,返回指针指向一个计时对象。Factory函数会“返回一个base class指针,指向新生成之derived class对象”:
TimeKeeper* getTimeKeeper(); //返回一个指针,指向一个TimeKeeper派生类的动态分配对象
为遵守factory函数的规矩,被getTimeKeeper()返回的对象必须位于heap。因此为了避免泄漏内存和其他资源,将factory函数返回的每一个对象适当地delete掉很重要:
TimeKeeper* ptk = getTimeKeeper(); //从TimeKeeper继承体系获得一个动态分配对象。
... // 运用它..
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成分(也就是声明于AtomicClockclass内的成员变量)很可能没被销毁,而AtomicClock的析构函数也未能执行起来。然而其base class成分(也就是TimeKeeper这一部分)通常会被销毁,于是造成一个诡异的“局部销毁”对象。这可是形成资源泄漏、败坏之数据结构、在调试器上浪费许多时间的绝佳途径喔。
消除这个问题的做法很简单:给base class一个virtual析构函数。此后删除derived class对象就会如你想要的那般。是的,它会销毁整个对象,包括所有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 { //一个二维空间点(2Dpoint)
public:
Point(int xCoord,int yCoord);
~Point();
private:
int x, yi;
};
如果int占用32bits,那么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计算机体系结构中将占用64bits(为了存放两个ints)至96bits(两个ints加上vptr):在64-bit计算机体系结构中可能占用64~128bits,因为指针在这样的计算机结构中占64bits。因此,为 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有个
... //non-virtual析构函数
};
乍看似乎无害,但如果你在程序任意某处无意间将一个pointer-to-SpecialString转换为一个pointer-to-string,然后将转换所得的那个string指针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::unorderedmap(见条款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 { //AwOV="Abstract w/oVirtuals"
public:
virtual~AWov()= 0; //声明purevirtual析构函数
};
这个class有一个pure virtual函数,所以它是个抽象class,又由于它有个virtual析构函数,所以你不需要担心析构函数的问题。然而这里有个窍门:你必须为这个pure virtual析构函数提供一份定义:
AWOV::~AWOV(){ } //pure virtual析构函数的定义
析构函数的运作方式是,最深层派生(most derived)的那个class其析构函数最先被调用,然后是其每一个base class的析构函数被调用。编译器会在Awov的derived classes的析构函数中创建一个对~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),它们并非被设计用来“经由base class接口处置derived class对象”,因此它们不需要virtual析构函数。
请记住
■ polymorphic(带多态性质的)base classes应该声明一个virtual析构函数。如果class带有任何virtual函数,它就应该拥有一个virtual析构函数。
■ Classes 的设计目的如果不是作为base classes 使用,或不是为了具备多态性(polymorphically),就不该声明virtual析构函数。
猜你喜欢
- 2025-01-16 C#13和 .NET9高级功能解析:.NET高手必备技能
- 2025-01-16 C#使用Autofac实现控制反转IoC和面向切面编程AOP
- 2025-01-16 C#设计模式(3)——工厂方法模式
- 2025-01-16 C# - 面向对象知识总结 082
- 2025-01-16 c#简单工厂、抽象工厂、反射
- 2025-01-16 C# 13 和 .NET 9 全知道 :9 处理文件、流和序列化 (1)
- 2025-01-16 C# 数据结构和算法 :03 数组和排序(五)
- 2025-01-16 从零开始自学C#基础的最后一天——集合
- 2025-01-16 多态 C#
- 2025-01-16 C#入门篇章—Class类专题
你 发表评论:
欢迎- 最近发表
- 标签列表
-
- oraclesql优化 (66)
- 类的加载机制 (75)
- feignclient (62)
- 一致性hash算法 (71)
- dockfile (66)
- 锁机制 (57)
- javaresponse (60)
- 查看hive版本 (59)
- phpworkerman (57)
- spark算子 (58)
- vue双向绑定的原理 (68)
- springbootget请求 (58)
- docker网络三种模式 (67)
- spring控制反转 (71)
- data:image/jpeg (69)
- base64 (69)
- java分页 (64)
- kibanadocker (60)
- qabstracttablemodel (62)
- java生成pdf文件 (69)
- deletelater (62)
- com.aspose.words (58)
- android.mk (62)
- qopengl (73)
- epoch_millis (61)
本文暂时没有评论,来添加一个吧(●'◡'●)