《深入理解C++11:C++ 11新特性解析与应用》——2.10 final/override控制

2.10 final/override控制

类别:部分人

在了解C++11中的final/override关键字之前,我们先回顾一下C++关于重载的概念。简单地说,一个类A中声明的虚函数fun在其派生类B中再次被定义,且B中的函数fun跟A中fun的原型一样(函数名、参数列表等一样),那么我们就称B重载(overload)了A的fun函数。对于任何B类型的变量,调用成员函数fun都是调用了B重载的版本。而如果同时有A的派生类C,却并没有重载A的fun函数,那么调用成员函数fun则会调用A中的版本。这在C++中就实现多态。

在通常情况下,一旦在基类A中的成员函数fun被声明为virtual的,那么对于其派生类B而言,fun总是能够被重载的(除非被重写了)。有的时候我们并不想fun在B类型派生类中被重载,那么,C++98没有方法对此进行限制。我们看看下面这个具体的例子,如代码清单2-23所示。


在代码清单2-23中,我们的基础类MathObject定义了两个接口:Arith和Print。类Printable则继承于MathObject并实现了Print接口。接下来,Add2和Mul3为了使用MathObject的接口和Printable的Print的实现,于是都继承了Printable。这样的类派生结构,在面向对象的编程中非常典型。不过倘若这里的Printable和Add2是由两个程序员完成的,Printable的编写者不禁会有一些忧虑,如果Add2的编写者重载了Print函数,那么他所期望的统一风格的打印方式将不复存在。

对于Java这种所有类型派生于单一元类型(Object)的语言来说,这种问题早就出现了。因此Java语言使用了final关键字来阻止函数继续重写。final关键字的作用是使派生类不可覆盖它所修饰的虚函数。C++11也采用了类似的做法,如代码清单2-24所示的例子。

在代码清单2-24中,派生于Object的Base类重载了Object的fun接口,并将本类中的fun函数声明为final的。那么派生于Base的Derived类对接口fun的重载则会导致编译时的错误。同理,在代码清单2-23中,Printable的编写者如果要阻止派生类重载Print函数,只需要在定义时使用final进行修饰就可以了。

读者可能注意到了,在代码清单2-23及代码清单2-24两个例子当中,final关键字都是用于描述一个派生类的。那么基类中的虚函数是否可以使用final关键字呢?答案是肯定的,不过这样将使用该虚函数无法被重载,也就失去了虚函数的意义。如果不想成员函数被重载,程序员可以直接将该成员函数定义为非虚的。而final通常只在继承关系的“中途”终止派生类的重载中有意义。从接口派生的角度而言,final可以在派生过程中任意地阻止一个接口的可重载性,这就给面向对象的程序员带来了更大的控制力。

在C++中重载还有一个特点,就是对于基类声明为virtual的函数,之后的重载版本都不需要再声明该重载函数为virtual。即使在派生类中声明了virtual,该关键字也是编译器可以忽略的。这带来了一些书写上的便利,却带来了一些阅读上的困难。比如代码清单2-23中的Printable的Print函数,程序员无法从Printable的定义中看出Print是一个虚函数还是非虚函数。另外一点就是,在C++中有的虚函数会“跨层”,没有在父类中声明的接口有可能是祖先的虚函数接口。比如在代码清单2-23中,如果Printable不声明Arith函数,其接口在Add2和Mul3中依然是可重载的,这同样是在父类中无法读到的信息。这样一来,如果类的继承结构比较长(不断地派生)或者比较复杂(比如偶尔多重继承),派生类的编写者会遇到信息分散、难以阅读的问题(虽然有时候编辑器会进行提示,不过编辑器不是总是那么有效)。而自己是否在重载一个接口,以及自己重载的接口的名字是否有拼写错误等,都非常不容易检查。

在C++11中为了帮助程序员写继承结构复杂的类型,引入了虚函数描述符override,如果派生类在虚函数声明时使用了override描述符,那么该函数必须重载其基类中的同名函数,否则代码将无法通过编译。我们来看一下如代码清单2-25所示的这个简单的例子。

在代码清单2-25中,我们在基类Base中定义了一些virtual的函数(接口)以及一个非virtual的函数Print。其派生类DerivedMid中,基类的Base的接口都没有重载,不过通过注释可以发现,DerivedMid的作者曾经想要重载出一个“void VNeumann(double g)”的版本。这行注释显然迷惑了编写DerivedTop的程序员,所以DerivedTop的作者在重载所有Base类的接口的时候,犯下了3种不同的错误:

如果没有override修饰符,DerivedTop的作者可能在编译后都没有意识到自己犯了这么多错误。因为编译器对以上3种错误不会有任何的警示。这里override修饰符则可以保证编译器辅助地做一些检查。我们可以看到,在代码清单2-25中,DerivedTop作者的4处错误都无法通过编译。

此外,值得指出的是,在C++中,如果一个派生类的编写者自认为新写了一个接口,而实际上却重载了一个底层的接口(一些简单的名字如get、set、print就容易出现这样的状况),出现这种情况编译器还是爱莫能助的。不过这样无意中的重载一般不会带来太大的问题,因为派生类的变量如果调用了该接口,除了可能存在的一些虚函数开销外,仍然会执行派生类的版本。因此编译器也就没有必要提供检查“非重载”的状况。而检查“一定重载”的override关键字,对程序员的实际应用则会更有意义。

还有值得注意的是,如我们在第1章中提到的,final/override也可以定义为正常变量名,只有在其出现在函数后时才是能够控制继承/派生的关键字。通过这样的设计,很多含有final/override变量或者函数名的C++98代码就能够被C++编译器编译通过了。但出于安全考虑,建议读者在C++11代码中应该尽可能地避免这样的变量名称或将其定义在宏中,以防发生不必要的错误。

时间: 2024-10-23 03:08:04

《深入理解C++11:C++ 11新特性解析与应用》——2.10 final/override控制的相关文章

《深入理解C++11:C++ 11新特性解析与应用》——第3章 通用为本,专用为末 3.1 继承构造函数

第 3 章 通用为本,专用为末 C++11的设计者总是希望从各种方案中抽象出更为通用的方法来构建新的特性.这意味着C++11中的新特性往往具有广泛的可用性,可以与其他已有的,或者新增的语言特性结合起来进行自由的组合,或者提升已有特性的通用性.这与在语言缺陷上"打补丁"的做法有着本质的不同,但也在一定程度上拖慢了C++11标准的制定.不过现在一切都已经尘埃落定了.在本章里读者可以看到这些经过反复斟酌制定的新特性,并体会其"普适"的特性.当然,要对一些形如右值引用.移动

深入理解C# 3.x的新特性(1): Anonymous Type

在C#3.0中,引入了一个新的Feature:Anonymous Method,允许我们已Inline的方式来定义Delegate,为Developer在Coding的时候带来了很大的便利.在C#3.0中,我们又有了另一个相似的Feature:Anonymous Type.Anonymous Type允许我们已Inline的方式的创建一个基于未知类型.具有所需数据结构的对象. 一.Anonymous Type Overview  在传统的编程模式中,对象依赖于一个既定的Type,我们只能在Typ

深入理解C# 3.x的新特性(2):Extension Method[上篇]

在C#3.0中,引入了一些列新的特性,比如: Implicitly typed local variable, Extension method,Lambda expression, Object initializer, Anonymous type, Implicitly typed array, Query expression, Expression tree. 个人觉得在这一系列新特性的,最具创新意义的还是Extension method,它从根本上解决了这样的问题:在保持现有Type

深入理解C# 3.x的新特性(2):Extension Method[下篇]

四.Extension Method的本质 通过上面一节的介绍,我们知道了在C#中如何去定义一个Extension Method:它是定义在一个Static class中的.第一个Parameter标记为this关键字的Static Method.在这一节中,我们来进一步认识Extension Method. 和C# 3.0的其他新特性相似,Extension Method仅仅是C#这种.NET Programming Language的新特性而已.我们知道,C#是一种典型的编译型的语言,我们编

深入理解C#3.x的新特性(4):Automatically Implemented Property

深入理解C#3.x的新特性系列在沉寂一个月之后,今天继续.在本系列前3部分中,我们分别讨论了Anonymous Type,Extension Method 和Lambda Expression,今天我们来讨论另一个实用的.有意思的New feature:Automatically Implemented Property. 一.繁琐的private field + public property Definition 相信大家大家已经习惯通过一个private field + public pr

深入理解C# 3.x的新特性(5):Object Initializer 和 Collection Initializer

深入理解C# 3.x的新特性系列自开篇以后,已经有两个月了.在前面的章节中,我们先后深入讨论了C# 3.x新引入的一些列新特性:Anomynous Type.Extension Method.Lambda Expression.Automatically Implemented Property,今天我们来讨论本系列的涉及的另外两个简单的Feature: Object Initializer 和 Collection Initializer. 一.           为什么要引入Object

[原创]深入理解C# 3.x的新特性(3):从Delegate、Anonymous Method到Lambda Expression

较之前一个版本,对于C# 3.x和VB 9来说,LINQ是最具吸引力的.基本上很多的新的特性都是围绕着LINQ的实现来设计的.借助Extension Method,我们可以为LINQ定义一系列的Operator.通过Lambda Expression我们可以为LINQ编写更加简洁的查询.我们可以说这些新的特性成就了LINQ,也可以说这些新特性就是为了实现LINQ而产生,但是我们应该明白,对于这些新引入的特性,LINQ并非他们唯一的用武之地,在一般的编程中,我们也可以使用它们. 继上一章,介绍Ex

《深入理解C++11:C++ 11新特性解析与应用》——2.14 本章小结

2.14 本章小结 在本章中,我们可以看到C++11大大小小共17处改动.这17处改动,主要都是为保持C++的稳定性以及兼容性而增加的. 比如为了兼容C99,C++11引入了4个C99的预定的宏.__func__预定义标识符._Pragma操作符.变长参数定义,以及宽窄字符连接等概念.这些都是错过了C++98标准,却进入了C99的一些标准,为了最大程度地兼容C,C++将这些特性全都纳入C++11.而由于标准的更新,C++11也更新了__cplusplus宏的值,以表示新的标准的到来.而为了稳定性

《深入理解C++11:C++ 11新特性解析与应用》——2.9 扩展的friend语法

2.9 扩展的friend语法 类别:部分人 friend关键字在C++中是一个比较特别的存在.因为我们常常会发现,一些面向对象程序语言,比如Java,就没有定义friend关键字.friend关键字用于声明类的友元,友元可以无视类中成员的属性.无论成员是public.protected或是private的,友元类或友元函数都可以访问,这就完全破坏了面向对象编程中封装性的概念.因此,使用friend关键字充满了争议性.在通常情况下,面向对象程序开发的专家会建议程序员使用Get/Set接口来访问类