要关闭选民,请帮助我改进问题,以便重新开启:我如何改进这个问题以便重新开放？
Herb Sutter 写道:
基类析构函数应该是公共的和虚拟的,或者是受保护的和非虚拟的.
根据该指南,如果您有一个具有公共非虚拟析构函数的类,则该类不应该用作基类.为什么不标记它final来强制执行？
但Sutter也写了以下内容,暗示final不需要使用:
重新使用"决赛是罕见的" - 嗯,他们有点.我不知道很多,在标准化过程中,Bjarne反复询问它解决的问题和应该使用的模式的例子,我不记得任何突出的主要问题.
另一个相关的引用,暗示现在final应该使用它,来自Scott Meyer的Effective C++,第7项:
如果您曾试图从标准容器或任何其他具有非虚拟析构函数的类继承,请抵制诱惑!(不幸的是,C++没有提供类似于Java的最终类或C#的密封类的派生防止机制.)
另一个数据点是标准库没有标记为"final"的类型,但其原因似乎是避免破坏代码.
这里有一个类似的问题,但不完全是重复,因为它错过了"受保护的非虚拟"选项:默认为使类为"final"或给它们一个虚拟析构函数？
根据该指南,如果您有一个具有公共非虚拟析构函数的类,则该类不应该用作基类.为什么不把它标记为最终执行？
因为它是适合某些情况的指南,但不是全部,所以为什么要 "强制"它呢？
通过virtual函数调用的动态多态性尚未配置,但这是非常好并且很好的禁止继承,但这不是我们使用继承的唯一场景.
C++是多范式的,开始实施仅适合用例子集的窄方法没有意义.从我所知道的,你的建议基本上归结为禁止人们使用继承,除非他们也将使用动态多态.
我通常将类声明为final除非它们是
我认为显式设计继承是一件好事（毕竟应该谨慎使用）。如果我不费心设计一个类作为基类，我会通过声明它来记录这一点final。如果后来我发现从该类派生会很有用，那么必须删除该类，这final是一个很好的机会来检查使其成为可行基类的其他条件是否得到满足。
我通常不声明 POD 类型，final因为我看不到这样做有任何好处，并且从它们派生有时对于利用空基优化很有用。
| 归档时间： |
|
| 查看次数： |
604 次 |
| 最近记录： |