override on non-virtual functions

Question

The C++11 FDIS it says

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
};

What if B::f would not have been marked virtual? Is the program ill-formed, then? Or is override then to be ignored`. I can not find any handling of this case in the std text.

Update 1/2 (merged) I forwarded a request to the C++ Editors to look into things. Thanks Johannes to pointing that out to me.

• "void f(long) override" does not override a function, esp. no virtual one,
• therefore it is not virtual
• therefore the text "If a virtual function is marked with..." does not apply
• therefore the example does not match the text.

But by realizing this I found, that the intention of the "override" contextual keyword can not be met: if a typo in the function name or the wrong argument type does make the function itself non-virtual, then the standard's text never applies -- and "override" is rendered useless.

The best possible solution may be

• putting "virtual" in front of the example's functions

Solution

What if B::f would not have been marked virtual? Is the program ill-formed, then?

Yes, it is. Because in order to override something, that something has to be virtual. Otherwise it's not overriding, it's hiding. So, the positive answer follows from the quote in your question.

Comments

[Mark B]

Can you provide a standard reference?

[towi]

I disagree: The formulation I quoted does not make any statement about "non virtual functions". Only the example does. Funnily enough void D::f(long); itself is not virtual, because it does not override virtual void B::f(int). Thus the quoted text does not apply for the added override behind D::f(long). Thats why I got confused...

[towi]

Why? The text I quoted only refers to "vertual functions". If B::f is not virtual, then the text does not apply.

[Armen Tsirunyan]

@towi: The quote says: If the function marked with virtual does not override... then the program is ill-formed. The term override can be applied only to virtual functions, so if the function, the signature of which coincides with your new function is not virtual, then this new function does not override it, therefore the quote applies

[towi]

Hmm, maybe you are right. Any "typo" that would lead to non-overriding would lead also to non-virtuality. That would make no sense.

[dolphy]

I'm still curious to see a reference for stating that "The term override can be applied only to virtual functions". The question is not in the semantics of whether you're overriding or hiding, the question is whether there is ambiguity in how a compiler is allowed to handle this case. Is there actual verbiage in the specification that prohibits applying the override identifier to a non-virtual function?

[Armen Tsirunyan]

@dolphy: There isn't any specific quote for that, because that is an implicit thing. I don't remember where exactly, but somewhere in the texts we read something along the lines of "...a virtual function may be overriden..."

[Branko Dimitrijevic]

@towi This text is really referring to D::f, not B::f. The functions D::f are still virtual but try to override a no-longer-virtual function B::f, hence both D::f functions are ill-formed.

[PlasmaHH]

@dolphy: I don't really think it is necessary, since override is a term closely tied to virtual functions in derived classes reimplementing those of the base. It is like the standard also does not have to define terms like polymorphic or call. Maybe ISO 2382 defines those terms (which is used by ISO14882 as a reference)

[dolphy]

Understood, and I certainly see (and agree with) Armen's point that this is kind of a non-sensical thing to those who understand the logical meanings of the terms. However, projects are touched by plenty of programmers who do not understand the logical meanings of the terms. Because of the nature of implicit virtual functions, I can see plenty of compilers out there taking the "easy way out" and not enforcing this distinction...simply because there's no rule that says they have to. For me, it's the possibility for compiler ambiguity that bugs me.

[Johannes Schaub - litb]

Ah wait, I just noticed and noticed that @towi had these insights too. Of course the reasoning in this accepted answer is flawed (and the spec's example for that paragraph is flawed too). 9.2p9 rejects the example, not the quoted text.

[Johannes Schaub - litb]

"so if the function, the signature of which coincides with your new function is not virtual, then this new function does not override it, therefore the quote applies" - no. Because the quote starts with "If a virtual function...". Putting override onto a function does not make it virtual.

[Armen Tsirunyan]

@Johannes: I don't understand what you're saying! Putting override ontp a function does not make it virtual, I agree. But I didn't say otherwise. I said that if the function in base class is not virtual then there is no way you can override it, which means that if you put the word override on any function that you think overrides the base's function, you'll get an ill-formed program

[Johannes Schaub - litb]

@Armen what you say in that comment is correct. But that is not what the quote says. The quote says considerably less. You seem to be in the impression that the function in the derived class is virtual, which it isn't.

[Admin]

The reference to this answer is here : en.cppreference.com/w/cpp/language/override .