Overriding inherited virtual functions
One way C++ supports code reuse is through inheritance. One base class implements common functionality. Then other classes inherit from it, essentially copying functionality from it. These other classes can add their own new functionality, or, more powerfully, they can override the base class functionality.
class Base
{
public:
virtual const char* type() { return "Base"; }
};
class Derived : public Base
{
public:
virtual const char* type() { return "Derived"; }
};
Overriding base class functionality is simple. Keeping such overrides working correctly is sometimes harder. The problem is that the override relationship is implicit: if the override doesn’t exactly match the signature of the desired function in the base class, it may not work correctly.
class Base
{
public:
// Perhaps as part of an incomplete refactoring,
// the base class's function changed its name.
virtual const char* kind() { return "Base"; }
};
class DerivedIncorrectly : public Base
{
public:
virtual const char* type() { return "Derived"; }
};
// BAD: code expecting kind() to work and sometimes
// indicate Derived-ness no longer will.
Making the override relationship explicit
Some languages (Scala, C#, probably others) provide the ability to mark a derived class’s function as an override of an inherited function. C++98 included no such ability, but C++11 does, through the contextual override keyword. When override is used, that virtual member function must override one found on a base class. If it does not, it is a compile error.
class Base
{
public:
virtual const char* kind() { return "Base"; }
};
class DerivedIncorrectly : public Base
{
public:
// This will cause a compile error: there's no type()
// method on Base that this overrides.
virtual const char* type() override { return "Derived"; }
// This will work as intended.
virtual const char* kind() override { return "Derived"; }
};
Introducing MOZ_OVERRIDE
The Mozilla Framework Based on Templates now includes support for the C++11 contextual override keyword, encapsulated in the MOZ_OVERRIDE macro in mozilla/Types.hmozilla/Attributes.h. Simply place it at the end of the declaration of the relevant method, before any = 0 or method body, like so:
#include "mozilla/Types.h"// MOZ_OVERRIDE has since moved... #include "mozilla/Attributes.h" // ...to here class Base { public: virtual void f() = 0; }; class Derived1 : public Base { public: virtual void f() MOZ_OVERRIDE; }; class Derived2 : public Base { public: virtual void f() MOZ_OVERRIDE = 0; }; class Derived3 : public Base { public: virtual void f() MOZ_OVERRIDE { } };
MOZ_OVERRIDE will expand to use the C++11 construct in compilers which support it. Thus in such compilers misuse of MOZ_OVERRIDE is an error. Even better, some of the compilers used by tinderbox support override, so in many cases tinderbox will detect misuse. (Specifically, MSVC++ 2005 and later support it, so errors in cross-platform and Windows code won’t pass tinderbox . Much more recent versions of GCC and Clang support it as well, but these versions are too new for tinderbox to have picked them up yet — in the case of GCC too new to even have been released yet. 🙂 )
What about NS_OVERRIDE?
It turns out there’s already a macro annotation to indicate an override relationship: NS_OVERRIDE. This gunky XPCOM macro expands to a user attribute under gcc-like compilers. It’s only used by static analysis right now, so its value is limited. Unfortunately its position is different — necessarily so, because in the C++11 override position it would attach to the return value of the method:
class OldAndBustedDerived : public Base
{
public:
NS_OVERRIDE virtual void f(); // annotates the method
__attribute__(...) virtual void g(); // its expansion
};
class Derived2 : public Base
{
public:
// But in the MOZ_OVERRIDE position, it would annotate
// f()'s return value.
virtual void f() __attribute__(...);
};
NS_OVERRIDE is now deprecated and should be replaced with MOZ_OVERRIDE. With a little work, static analysis with new-enough compilers can likely look for MOZ_OVERRIDE just as easily as for NS_OVERRIDE. And since MOZ_OVERRIDE works in non-static analysis builds, it’s arguably better in the majority of cases anyway. If you’re looking for an easy way to improve Mozilla code, changing NS_OVERRIDE uses to use MOZ_OVERRIDE would be a simple way to help.
Summary
If you’ve overridden an inherited virtual member function and you’re worried that that override might silently break at some point, annotate your override with MOZ_OVERRIDE. This will cause some compilers to enforce an override relationship, making it much less likely that your intended relationship will break.