虚函数并不总是适用,所以C++中默认方法为非虚函数,原因有三:
1.虚函数有时会带来很大的开销
2.如果没有继承关系,那么函数是否为虚函数根本无关紧要,有时候我们编写一个类时,可能会不想考虑进行派生。
3.在在使用继承关系的程序中,也不需要把所有函数都设为虚函数,示例代码在p126,这个代码需要好好思考。
必须使用虚函数的情况:当想删除一个表面上指向基类对象,而实际上指向派生类对象的指针的时候,就需要虚析构函数
下述文字摘自http://blog.sina.com.cn/s/blog_51409e8f01009jqg.html,对虚函数进行了很好的剖析。
C++是一个恶草丛生的地带,虚拟机制是很重要,但是很危险的一个C++特性,所以有必要对此作一下阐述,希望能对大家有所帮助。什么是虚函数
简单地说,就是在成员函数前加关键字virtual,这样这个成员函数就变成了虚函数。
虚函数的思想是从Simula借来得,在C++里面算得上最显著的特征。
在虚函数开始被加进来的时候,人们对这个东东抱有强烈的抵触意识,有一种常见的说法是:虚函数不过是一个蹩脚的函数指针,完全是多余的。更有甚者,说什么良好的设计根本就不需要虚函数所提供的那些可扩展性和开放性。在这些观点别大肆批判之后,又产生了一种变形:虚函数值不过是一种低效的形式。为此大师们展开了一场保家卫国的战争,道路十分曲折,我不打算把这些观点重复一遍,如果你十分感兴趣,可以参考:The D&V of C++,TC++PL,What is OOP?在这里呢,我大概说一下他的重要性:
从面向对象的角度看,如果没有虚函数,C++ 就不能算是面向对象的了。虽然重载很好,但不要忘了,它只是C概念中传递一个结构的指针给函数的句法装饰而已;虽然标准库包含了许多模板以实现同样非常好的“泛型编程”技术,但虚函数仍然是用C++进行面向对象编程的核心,通过在子类中override基类中的虚函数,就可以达到OO中的一个重要特性——多态。
从商业角度看,如果没有虚函数,C++就不是面向对象的了,自然的我们也就没有什么理由要从C转到C++了。如果没有面向对象,我们就没有足够的理由去培训开发者、开发新工具,如果我们只有C++类的语法而没有面向对象的话,就不会减少维护成本,而实际上会增加培训成本。
从语言的角度看,没有虚函数的C++不是面向对象,用类编程而没有动态绑定则只能算作“基于对象”,而不是“面向对象”。抛弃了虚函数,实际上就是抛弃了OO!结果就变成了早期的Ada语言。
虚函数和非虚函数调用方式有什么不同
非虚成员函数是静态确定的,换句话说,该成员函数在编译时就会被静态地选择。
虚函数和重载有什么不同
虚函数遭遇内联
呵呵,一个有趣的问题,但是回答往往不尽人意,特别是初学者更是如此。我发现初学者普遍认为序函数不可能是内联的,原因看起来似乎也很明显:
其实,在许多情况下,虚函数是都是静态确定的--特别是当派生类的虚方法调用其基类的方法时。你也许很奇怪为什么会这么做呢?答案很简单,就两个字:封装。一个很好的例子是,派生类的析构函数引起基类的析构函数的调用。除了最初的函数,其他的函数都是静态确定的。如果不确定基类析构函数为内联,就不能发挥这一优点。特别是在继承层次很深,并且许多对象被析构的时候,对虚函数进行内联毫无疑问会大大提高程序的运行效率。
class Shape
{
public:
};
inline void Shape::draw()
{ cout<<"Shape::draw()"<<endl; }
class Rectangle:public Shape
{
public:
};
Shape* p=new Rectangle;
p->draw();
这个draw是内联的吗?不,当然不是。这要通过虚函数机制在运行时刻确定。这一调用被转换为类似于下面的一些东西:
1代表draw在虚函数列表中的位置。因为这个draw的调用通过函数指针_vptr[1]来实现,编译器不能再编译时刻确定调用函数的地址,所以函数不可为内联。
当然,内联虚函数draw的定义必须在某个地方出现以保证执行代码调用的恰当的运行。也就是,至少需要一个定义来在虚函数列表中放置它的地址。编译器如何确定在什么时候生成那个定义呢?一个方法是在虚函数列表生成的时候就生成定义。这意味着为每个类的实例生成一个虚函数列表。每一个内联函数的实例也同时产生。
在一个可执行程序中为一个类要生成多少虚函数列表呢?恩,虽然标准对虚函数的行为做了一些规定;但是没有对实现做出约束。因为虚函数列表没有在标准中做出规定。所以明显也不会去规定如何控制虚函数列表或者生成多少实例。
此外,C++标准现在要求内联函数表现得好象在一个程序中只有一个内联函数的定义,即使函数是在不同的文件中定义的。新的规定是使实现表现为只有一个实例产生。当标准的这个特性被广泛实现的时候涉及到代码膨胀的潜在问题也将会消失。
虚函数的开销
人们一提到虚函数,首先想到的是多态,紧接着想到的就是开销(至少我开始的时候就是这样子的),那么虚函数的开销来自哪里?开销究竟有多大?
在理论上来讲,虚函数所带来的动态开销主要依赖于3个方面:编译器、操作系统和机器。但是在现实中,几乎所有的编译器都以同样的方式操作。调用一个虚函数的开销主要来自于2个方面,一个是如果虚函数不是内联的,就要增加一些额外的机器指令,不过一般来说也就增加3-5个机器指令(是从那里看的,既不清楚了,不过这个结论我倒是记得很清楚),从时间上来讲,与一个非虚拟函数相比,也就多花费10%-20%的开销,如果有几个参数,这个比例会更小。同时,函数调用的连接开销通常只是总的开销的一小部分,所以基本上来讲,序函数的开销可以忽略不计。当然,如果你在程序中大量运用虚拟函数,效率自然就会有很大的下降,积少成多么。
虚析构函数的时机
析构函数能不能是虚拟的,这个问题大家都比较清楚:能!那么什么时候把析构函数设计成虚拟的呢?
初学者往往会犯这样的错误:基类析构函数当然应该始终是虚拟的!
看来这个规则比较的容易记住,当然她也有自己的理论基础(虽然分析的不怎么全面):一个类既然可以作为基类,那么他就打算多态的使用,因此就应该将析构函数设成虚拟的;另外由于目前大多数编译器都采用vtbl的手法实现虚拟函数,而vtbl是一个类共享的,所有的类的实例都共享这个vtbl,换句话说,如果一个类里面已经有了一个虚函数,那么把析构函数声明为一个虚函数不会对每个实例对象有什么空间开销。
不过这样的分析还是不准确,例如下面的例子
class Base
更加准确的规则如下:如果派生类有一个特殊的析构函数,并且我们也需要动态的删除基类的指针,那么这个基类的析构函数就应该是虚拟的。
虚构造函数
既然我们有了虚析构函数,那么有没有虚构造函数呢?
很不幸的是,没有!原因在于虚拟调用是一种能够在给定信息不完全的情况下工作的机制。特别地,虚拟允许我们调用某个函数,对于这个函数,仅仅知道它的接口,而不知道具体的对象类型。但是要建立一个对象,你必须拥有完全的信息。特别地,你需要知道要建立的对象的具体类型。因此,对构造函数的调用不可能是虚拟的。
不过,还能够给大家一个安慰的是,我们可以模拟虚构造函数。
在TC++PL第15.6.2.节Bjarne大师给出了一个例子。无独有偶,在《Thinking in C++》的作者也给出了一种模拟虚构造函数的方法,基本是这样的。
// 给出一个抽象类shape,里面有要提供的接口
class shape
{
public:
shape();
virtual ~shape();
virtual void draw();
// ....
};
class circle : public shape
{
public:
circle(); ~circle();
void draw();
// ...
};
class rectangle : public shape
{
public:
rectangle(); ~rectangle();
void draw();
// ...
};
// 再给一个shapewrap封装一下
class shapewarp
{
protected:
shape *object;
public:
shapewrap(const string &type)
{
if (type=="circle")
object=new circle;
else if (type=="rectangle")
object=new rectangle;
else
{
// ...
}
}
~shapewrap() { delete object; }
void draw() { object->draw(); }
};
为什么成员函数默认不是virtual的?
成员函数的模板可不可以是Virtual的?