自从使用c++11以来，我一直注意到在从接口派生的类中，我总是使用override说明符（对我来说，人们最想知道的是基类中的虚拟签名何时发生变化）。我几乎觉得连续指定override是错误的，这就引出了我的问题：为什么标准委员会没有决定将override设为默认值（在虚拟机的基本签名改变时生成编译器错误），同时添加一个关键字来显式地“不关心”，例如override_ignore（我不认为有人会想忽略这个）？
yiytaume1#
正如Nathan奥利弗所述：向后兼容性（一个必要的缺点）尽管在代码库中大量替换术语“override”相当容易，但它只会成为本已不情愿的编程社区的另一个障碍。另一个要点是代码可读性，如果你正在维护一个非常大的代码库的一小部分，在你的子类中有一个override说明符来提醒你：
C++并不专注于使代码本身尽可能的小和高效--这就是为什么它很少赢得任何代码高尔夫挑战。相反，它是一种专注于严谨性和明确你所做的一切的语言。至少，这是我对这种语言的看法。以及为什么当我需要在复杂程序中保持清晰时，它是我的首选语言（尽管一些常见的操作比许多其他语言需要更多的时间来写出）。
pbpqsu0x2#
还考虑以下情况：
struct A { virtual void foo(); } struct B: public A { virtual void fog() override; }
您输入了错误的函数 name（fog而不是foo），这段代码将给您带来编译错误。但是，使用默认重写方法，编译器将永远不会知道有错误。
fog
foo
2条答案
按热度按时间yiytaume1#
正如Nathan奥利弗所述：向后兼容性（一个必要的缺点）尽管在代码库中大量替换术语“override”相当容易，但它只会成为本已不情愿的编程社区的另一个障碍。
另一个要点是代码可读性，如果你正在维护一个非常大的代码库的一小部分，在你的子类中有一个override说明符来提醒你：
C++并不专注于使代码本身尽可能的小和高效--这就是为什么它很少赢得任何代码高尔夫挑战。相反，它是一种专注于严谨性和明确你所做的一切的语言。至少，这是我对这种语言的看法。以及为什么当我需要在复杂程序中保持清晰时，它是我的首选语言（尽管一些常见的操作比许多其他语言需要更多的时间来写出）。
pbpqsu0x2#
还考虑以下情况：
您输入了错误的函数 name（
fog而不是foo），这段代码将给您带来编译错误。但是，使用默认重写方法，编译器将永远不会知道有错误。