【c++】虚函数描写叙述符override

时间:2022-05-13 02:35:11

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

代码清单2-25

struct Base {

    virtual void Turing() = 0;

    virtual void Dijkstra() = 0;

    virtual void VNeumann(int g) = 0;

    virtual void DKnuth() const;

    void Print();

};

struct DerivedMid: public Base {

    // void VNeumann(double g);

    // 接口被隔离了,曾想多一个版本号的VNeumann函数

};

struct DerivedTop : public DerivedMid {

    void Turing() override;

    void Dikjstra() override;           // 无法通过编译,拼写错误,并不是重载

    void VNeumann(double g) override;   // 无法通过编译,參数不一致,并不是重载

    void DKnuth() override;             // 无法通过编译,常量性不一致,并不是重载

    void Print() override;              // 无法通过编译,非虚函数重载

};

// 编译选项:g++ -c -std=c++11 2-10-3.cpp

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

函数名拼写错,Dijkstra误写作了Dikjstra。

函数原型不匹配,VNeumann函数的參数类型误做了double类型,而DKnuth的常量性在派生类中被取消了。

重写了非虚函数Print。

假设没有override修饰符,在代码清单2-25中,DerivedTop作者的4处能够编译过去 可是与他的愿意(想重载虚函数)有严重的偏差了 可是编译器不报错,继续编译下去 这样就难排查了。加上keywordoverride
这样编译器能够辅助检查是不是正确重载 。
假设没有override修饰符 DerivedTop的作者可能在编译后都没有意识到自己犯了这么多错误。由于编译器对以上3种错误不会有不论什么的警示。这里override修饰符则能够保证编译器辅助地做一些检查。我们能够看到,在代码清单2-25中,DerivedTop作者的4处错误都无法通过编译。

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

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

建议:假设派生类里面是像重载虚函数 就加上keywordoverride 这样编译器能够辅助检查是不是正确重载,假设没加这个keyword 也没什么严重的error 仅仅是少了编译器检查的安全性