实现接口类纯虚方法的方法也应该声明为虚方法吗?

否-基类中声明为虚的每个函数方法在所有派生类中都将是虚的。

但是好的编码实践告诉我们要将这些方法声明为虚拟的。

virtual 在派生类重写声明中是可选的,但为了清楚起见,我个人将其包括在内。

真正的需要-不是。一旦一个方法在基类中声明为虚方法,它对于所有派生类都保持虚。但是,最好知道哪个方法是虚拟的,而不是在基类中检查它。而且,在大多数情况下,您不能确定您的代码是否是派生的(例如,如果您正在为某家公司开发一些软件)。正如我所说,这不是一个问题,正如曾经声明为虚拟的,它保持虚拟,但以防万一。(:

不需要将它们标记为虚拟的。

首先,我认为虚拟向读者宣传,您希望派生类重写虚拟来做一些有用的事情。如果您正在实现虚操作,那么虚方法可能与类的类型无关:在这种情况下,将其标记为虚操作是愚蠢的。考虑:

class CommsObject {
   virtual OnConnect();
   virtual OnRawBytesIn();
};

class XMLStream : public CommsObject {
    virtual OnConnect();
            OnRawBytesIn();
    virtual OnXMLData();
};

在这个例子中,onConnect在这两个类中都被记录为虚拟的,因为它的后代总是希望知道这一点是有意义的。onrawbytesin从xmlstream“导出”是没有意义的,因为它使用它来处理原始字节,并生成解析的数据——它通过onxmldata()通知这些数据。

在做了所有这些之后,我认为第三个类的维护者,看看xmlstream,可能会认为创建自己的onrawbytes函数并期望它作为一个正常的重载函数工作是“安全的”——也就是说,基类将调用内部正确的函数,而外部的Ne会屏蔽内部的onrawbytes。

因此,省略虚拟元素隐藏了类使用者的重要细节,并使代码以意想不到的方式运行。

因此,我做了一个完整的循环:不要试图用它来暗示一个函数的预期用途——一定要用它来暗示函数的行为:将函数标记为“虚拟一致”,这样下游程序员就必须读取更少的文件来了解函数在被重写时的行为。

不,它是不需要的,而且它也不能防止任何编码错误,尽管许多编码人员更愿意这样做。

一旦C++ 0x成为主流,你就可以使用 override 改为说明符。

一旦“虚拟”,它就一直虚拟到最后一个孩子。另外,这就是C++的特性。

如果您从不从类派生,那么将其方法虚化是没有意义的。