Override identifier after destructor in C++11

Question

Does the override identifier after virtual destructor declaration have any special meaning?

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

    virtual int Method() const
    {}
};

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

    virtual int Method() override // error: marked override, but does not override - missing const
    {}
};

Using override identifier on virtual method is useful as check: compiler will report error when the Base virtual method is actualy not overriden.

Does override on virtual destructor has any meaning/function too?

Ironclad

What does the compiler tell you about it? – Red

About ~Derived() override it doesn't tell anything, it compiles without any trouble. My point was if it has any special meaning. Method() override is of course error, as it's missing const. (I included it as example) – Ironclad

It does NOT compile if the base is not virtual. – Red

Answer 1

It is not override that has special meaning, but the destructor itself:

10.3 Virtual Functions

6/Even though destructors are not inherited, a destructor in a derived class overrides a base class destructor declared virtual; see 12.4 and 12.5.

If you take this in conjunction with the previous clause:

5/If a virtual function is marked with the virt-specifier override and does not override a member function of a base class, the program is ill-formed. [ Example:

struct B { 
    virtual void f(int); 
}; 

struct D : B
{ 
    void f(long) override; // error: wrong signature overriding B::f
    void f(int) override; // OK 
}; 

—end example ]

you can see that if a destructor is marked override but the base class does not have a virtual destructor, the program is ill-formed.

Joachima

Unfortunately VS2010 gives "error C3665: 'MyClass::~MyClass' : override specifier 'override' not allowed on a destructor". Perhaps the behaviour is improved in more modern compilers... – Bondmaid

Is it recommended practice to mark the destructor with override in derived classes assuming that it is virtual in the base class? Sutter and Meyers offer clear guidelines indicating that you should use override whenever overriding virtual functions but they do not specifically discuss the destructor. I can't see how it would hurt but do programmers actually do this? – Lingcod

FYI re: @TimMB's comment - VS 2017 does allow override on a virtual dtor in a derived class. – Highpriced

Am I missing something here? Typically the destructor in a derived class does not "override" the virtual one in the base class like a virtual method would. It is complementary - both the destructors are called as the object gets torn down. Marking a destructor with override seems totally incorrect to me. I reckon a program should be deemed ill formed if you derive from a base class using a non-virtual destructor. – Janycejanyte

@DavidMcCabe I reckon a program should be deemed ill formed if you derive from a base class using a non-virtual destructor. You're assuming that there shall be polymorphic usage of the derived class via a base class pointer. It's perfectly legit to have a non-virtual base clas destructor in case one's never going to use something like Base* ptrBase = derivedPtr for manipulating the Derived instance. – Selfgoverned

...except it wasn't legit in VS2010 and the standard absolutely doesn't explicitly state that it is legit. I don't understand why you would ever want to declare inheritance without legally being able to utilise it using a misleading specifier. I hope this never becomes canon. EDIT -from here looks like it is now considered bad practice – Janycejanyte

Answer 2

Yes. If the base destructor is not virtual then the override marking will cause the program to not compile:

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

class Derived : public Base
{
public:
    virtual ~Derived() override //error: '~Derived' marked 'override' but does
                                //        not override any member functions
    {}
};

Hudspeth

Is there any reason to use virtual and override together? Is there a special case for destructors? I think the convention wisdom is to not use both, as override makes virtual redundant for normal methods, but I'm not sure about destructors. – Iceberg

Personal opinion is that it's up to the coding conventions of a given organization and the individual. I use both at the moment out of force of habit. If I'm overriding a virtual function out of habit I add the virtual qualifier. That habit remains even after the introduction of the override keyword. – Sheley

@MarkLakata, they still have separate meaning. You can override a parent method without your own method being virtual to your descendents if you so choose. – Willams

@yano, that's not true, if something is declared virtual in a base class, it's implicitly virtual in every derived class. However, you can shadow (not override) a non-virtual base class method with a virtual one in a derived class. – Backstop

What @Willams talks about is the final keyword, which ensures a method cannot be overriden in derived classes while it was originally a virtual method. – Oven

@BalázsKovacsics and Pato Thanks for the clarifications/corrections. – Willams