我应该总是使用override关键字吗?

7
我知道引入 override 语境关键字是为了编写更安全的代码(通过检查具有相同签名的 virtual 函数),但我对此不感到满意,因为每次想要重写 virtual 函数时都写 override 似乎对我来说是多余的。
对于99%的情况不使用 override 语境关键字是否是一种不好的做法? 为什么/何时应该使用它(当我们错误地隐藏虚函数时,编译器警告并不足够)?
编辑:换句话说,在C++11中使用 override 语境关键字的优点是什么,而在C++03中,如果我们错误地隐藏虚函数而没有使用 override 语境关键字,则始终会收到编译器警告?

你能解释一下为什么你认为这是多余的吗? - user2672107
3个回答

9
override关键字非常有用,我建议一直使用
如果你拼错了虚函数,它会编译通过,但在运行时程序将调用错误的函数。它将调用基类函数而不是你的覆盖函数。
这可能是一个非常难以发现的错误。
#include <iostream>

class Base
{
public:
    virtual ~Base() {}

    virtual int func()
    {
        // do stuff for bases
        return 3;
    }
};

class Derived
: public Base
{
public:

    virtual int finc() // WHOOPS MISSPELLED, override would prevent this
    {
        // do stuff for deriveds
        return 8;
    }
};

int main()
{
    Base* base = new Derived;

    std::cout << base->func() << std::endl;

    delete base;
}

9
请注意,现在省略virtual可能会更加简洁,即int finc() override - TemplateRex

3

注解是一种上下文关键字,它们用于澄清代码,确保任何阅读代码的人都能意识到它是一个覆盖超类或接口中的函数。

如果原本被覆盖的特性被删除,编译器也会发出警告,这时你可能想考虑删除自己的函数。

据我所知,如果您省略注解,不会发生什么不好的事情。这既不对也不错。就像您已经正确指出的那样:注解是为了编写更安全的代码而引入的

但是:它们不会在任何功能上改变您的代码

如果您作为单个程序员在自己的项目上工作,使用它们与否可能并不重要。然而,坚持一种风格(即使用或不使用它们)是良好的实践。任何介于两者之间的东西,比如有时使用它们,有时不使用它们,只会引起混乱。

如果您在团队中工作,应该与您的团队成员讨论这个话题,并决定是否全部使用它们。


1
我需要指出,在回答之后,我发现了 c++ 标签(以及关于 c++ 的编辑)。起初,我认为这一切都是关于 Java 的。然而,在我看来,注释的概念对两种语言都是相同的,因此它不应该有所区别。但也许有人想要确认我的答案或者进行必要的编辑。 - Jonas Maurer
编译器还可以在原本被覆盖的特性被删除时发出警告,但在C ++中则会导致编译错误。顺便说一句,您是正确的,使用override关键字将增加代码的可读性,但我想知道为什么C ++社区仅为了可读性添加了一个关键字!? :-P - Sadeq
2
我们发明了C、C++等编程语言,因为阅读/编写机器码(零和一)或汇编代码很麻烦。编程语言的发明是为了一个目的:使编程更容易(并且更可读)。每种编程语言都有不同的概念,以实现这一目标。 顺便说一下,计算机科学家在创建新代码的10%的时间里,修改现有代码的20%的时间,最后70%的时间则是试图弄清楚已经存在的代码实际上在做什么。所以,在90%的情况下,可读性确实会产生影响。 - Jonas Maurer

1
在C++11中使用override关键字的优势是什么,而我们如果错误地隐藏虚函数,则一直会得到编译器警告?
几乎没有!但是:
这取决于您的构建规则接受多少警告。如果您说每个警告都必须修复,那么您将获得相同的结果,直到您使用一个会给您警告的编译器。
我们已经决定始终使用override并删除覆盖方法上的virtual。因此,“开销”为零,并且代码在“误用时产生错误”的意义上是可移植的。
我个人喜欢这个新功能,因为它使语言更清晰。如果您说这是一个override,它将被检查!在您的场景中,如果我们想添加一个具有不同签名的新方法,我们将不会收到错误的警告,这很重要!

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接