Should methods that implement pure virtual methods of an interface class be declared virtual as well?

Question

I read different opinions about this question. Let's say I have an interface class with a bunch of pure virtual methods. I implement those methods in a class that implements the interface and I do not expect to derive from the implementation.

Is there a need for declaring the methods in the implementation as virtual as well? If yes, why?

Answer 1

Real need - no. Once a method is declared as virtual in the base class, it stays virtual for all derived classes. But it's good to know which method is virtual and which - not, instead of checking this in the base class. Also, in most cases, you cannot be sure, if your code will be derived or not( for example, if you're developing some software for some firm). As I said, it's not a problem, as once declared as virtual, it stays virtual, but just in case .. (:

Answer 2

If you never derive from a class then there is no point making its methods virtual.

Answer 3

No - every function method declared virtual in the base class will be virtual in all derived classes.

But good coding practices are telling to declare those methods virtual.

Answer 4

virtual is optional in the derived class override declaration, but for clarity I personally include it.

Answer 5

There is no requirement to mark them virtual.

I'd start by arguing that virtual advertises to readers that you expect derived classes to override the virtual to do something useful. If you are implementing the virtual to do something, then the virtual method might have nothing to do with the kind of thing your class is: in which case marking it virtual is silly. consider:

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

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

In that example, OnConnect is documented as virtual in both classes because it makes sense that a descendent would always want to know. OnRawBytesIn doesn't make sense to "Export" from XMLStream as it uses that to handle raw bytes, and generate parsed data - which it notifies via OnXMLData().

Having done all that, I'd then argue that the maintainer of a 3rd class, looking at XMLStream, might think that it would be "safe" to create their own OnRawBytes function and expect it to work as a normal overloaded function - i.e. the base class would call the internal correct one, and the outer one would mask the internal OnRawBytes.

So omitting the virtual has hidden important detail from consumers of the class and made the code behave in unexpected ways.

So ive gone full circle: Don't try to use it as a hint about the intended purpose of a function - DO use it as a hint about the behaviour of the function: mark functions virtual consistently so downstream programmers have to read less files to know how a function is going to behave when overridden.

Answer 6

No, it is not needed and it doesn't prevent any coding errors although many coders prefer to put it.

Once C++0x becomes mainstream you'll be able to use the [[override]] attribute instead.

Answer 7

Once 'virtual', it's virtual all the way down to the last child. Afaik, that's the feature of the c++.