Gotcha #77: Failure to Distinguish among Overloading, Overriding, and Hiding

In C++, overloading is simply the use of the same function identifier for different functions declared in the same scope. That last proviso is important:

bool process( Credit & ); 
bool process( Acceptance & );
bool process( OrderForm & );

These three global functions are clearly overloaded. They share the process identifier and are declared in the same scope. The compiler will distinguish among them by the actual argument used in the call to process. That makes sense. If I ask to process an Acceptance, I'd expect the call to resolve to the second process function above, not the first or third. In C++, the name of a function is composed of a combination of the function's identifier (in this case, process) and the types of the formal arguments in the function's declaration. Let's embed these three functions in a class:

class Processor { 
 public:
   virtual ~Processor();
   bool process( Credit & );
   bool process( Acceptance & );
   bool process( OrderForm & );
   // . . .
};

They're still overloaded, and the compiler will still be able to perform the proper resolution based on the actual argument to the member function. The virtual destructor in the Processor class indicates that its designer intended it to be used as a base class, so we should feel free to extend its functionality through derivation:

class MyProcessor : public Processor { 
 public:
   bool process( Rejection & );
   // . . .
};

But not like this. The derived class process function doesn't additionally overload the base class process functions. It hides them:

Acceptance a; 
MyProcessor p;
p.process( a ); // error!

When the compiler looks up the name process in the scope of the derived class, it finds a single candidate function. This function is declared to take a Rejection formal argument, so we have an argument mismatch (unless there is some way to convert an Acceptance into a Rejection). End of discussion. The compiler will not continue its search for candidate process functions into enclosing scopes. The derived class process is declared in the scope of the derived class, not of the base class, and therefore can't overload the base class functions.

It's possible to import the base class declarations into the derived class scope with a using-declaration:

class MyProcessor : public Processor { 
 public:
   using Processor::process;
   bool process( Rejection & );
   // . . .
};

Now all four names are present in the same scope, and the derived class process function additionally overloads the three functions explicitly imported into the derived class scope. Note that this is not necessarily an exemplary design practice, because it's complex, and a complex design is always inferior to a simple design unless it has some compensating merit.

In this case, a Rejection can be processed only through the MyProcessor interface, and a compile-time error will result if we attempt to process a Rejection with the base class Processor interface. If a Rejection can be converted to an Acceptance, OrderForm, or Credit, however, the call will succeed under either interface but will exhibit different behavior.

Overriding can occur only in the presence of a base class virtual function. Period. Overriding has nothing whatsoever to do with overloading. A nonvirtual base class function cannot be overridden, only hidden:

class Doer { 
 public:
   virtual ~Doer();
   bool doit( Credit & );
   virtual bool doit( Acceptance & );
   virtual bool doit( OrderForm & );
   virtual bool doit( Rejection & );
   // . . .
};
class MyDoer : public Doer {
 private:
   bool doit( Credit & ); // #1, hides
   bool doit( Acceptance & ); // #2, overrides
   virtual bool doit( Rejection & ) const; // #3, doesn't override
   double doit( OrderForm & ); // #4, an error
   // . . .
};

(Please note that the Doer classes above are for illustration only and are not intended to exemplify good design practice. In particular, it's only rarely acceptable to overload virtual functions. See Gotcha #73.)

The doit function labeled #1 above does not override the corresponding base class function, because the base class function is not virtual. It does, however, hide all four base class doit functions.

The function labeled #2 does override the corresponding base class function. Note that access level has no effect on overriding. It doesn't matter that the base class function is public and the derived class function is private or vice versa. Conventionally, an overriding derived class function has the same access level as the corresponding base class function. In some cases, however, it may be desirable to depart from this standard practice:

class Visitor { 
 public:
   virtual void visit( Acceptance & );
   virtual void visit( Credit & );
   virtual void visit( OrderForm & );
   virtual int numHits();
};
class ValidVisitor : public Visitor {
   void visit( Acceptance & ); // overrides
   void visit( Credit & ); // overrides
   int numHits( int ); // #5, nonvirtual
};

In this case, the hierarchy designer has decided to allow customization of the base class behavior but would still like to require users of the hierarchy to employ the base class interface. The designer does this by declaring the base class member functions public but overriding them with private derived class functions.

Note also that the use of the keyword virtual in the derived class is purely optional when overriding a base class function. The meaning of the derived class function declaration is precisely the same with or without the presence of the keyword:

class MyValidVisitor : public ValidVisitor { 
   void visit( Credit & ); // overrides
   void visit( OrderForm & ); // overrides
   int numHits(); // #6, virtual, overrides Visitor::numHits
};

A common misconception is that the absence of the virtual keyword in an overriding derived class function will prevent that function from being over ridden itself in more derived classes. That is not the case, and MyValid Visitor::visit( Credit & ) overrides the corresponding functions in ValidVisitor and Visitor.

It's also perfectly valid for a derived class to override remote base class functions. MyValidVisitor::visit( OrderForm & ) overrides the corresponding function in Visitor.

It's even legal for a derived class to override a remote base class function that isn't visible in the scope of the derived class. For example, the function labeled #5, ValidVisitor::numHits, doesn't override the base class function Visitor::numHits, but it does hide the base class function from more derived classes. In spite of this hiding, the function MyValidVisitor::numHits does override Visitor::numHits.

The member function of MyDoer labeled #3 is subtle. It is virtual, but only because it's so declared. It doesn't actually override a base class virtual because it's a const member function, and the base class has no corresponding virtual const member function. Constness is part of the function signature (see Gotcha #82).

The member function of MyDoer labeled #4 above is in error. It overrides the corresponding base class virtual function, but it doesn't have a compatible return type; the base class function returns bool, and the derived class version returns double. This is a compile-time error.

In general, if a derived class function overrides a base class function, it must have the same return type. This is to ensure static type safety during runtime binding. A derived class virtual function is usually invoked through the base class function's interface (that's why we have virtual functions, after all). The compiler must generate code that assumes that the type of value returned from the function call—whether it's actually bound at runtime to the base class function or to an overriding derived class function—is the one declared in the base class.

In the case of the illegal function declaration labeled #4, the derived class function would attempt to copy an object that is sizeof(double) bytes into a location reserved for the return value of sizeof(bool) bytes. Even if the sizes are compatible (that is, bools are at least as big as doubles) it is unlikely a double, when interpreted as a bool, would give a consistently reasonable result.

This rule has an exception for what are known as "covariant return types." (Don't confuse covariance with contravariance. See Gotcha #46.) The return types of a base class member function and an overriding derived class function are covariant if they are pointers or references to classes and the class type in the derived class function return has an is-a relationship to the class type in the base class function return. That's a mouthful, so let's look at two canonical examples of covariant return types:

class B { 
   virtual B *clone() const = 0;
   virtual Visitor *genVisitor() const;
   // . . .
};
class D : public B {
   D *clone() const;
   ValidVisitor *genVisitor() const;
};

The clone function returns a pointer to a duplicate of the object making the clone request (this is an instance of the Prototype pattern; see Gotcha #76). Typically, the request is made through the base class interface, and the precise type of the cloned object is not known:

B *aB = getAnObjectDerivedFromB(); 
B *anotherLikeThat = aB->clone();

On occasion, however, we'll have more precise information about the type, and we'd like to avoid losing that information or forcing a downcast:

D *aD = getAnObjectThatIsAtLeastD(); 
D *anotherLikeThatD = aD->clone();

Without the covariant return, we'd be forced to downcast the return value from B * to D *:

D *anotherLikeThatD = static_cast<D *>(aD->clone()); 

Note that, in this case, we're able to use the efficient static_cast operator in preference to dynamic_cast, because we know that D's clone operation returns a D object. In other contexts the use of dynamic_cast (or avoiding a cast entirely) would be safer and preferable.

The genVisitor function (an instance of the Factory Method pattern; see Gotcha #90) illustrates that the classes in the covariant returns don't have to be related to the hierarchy in which the functions occur.

The overriding mechanism in C++ is a flexible and useful tool. However, this utility comes at the cost of some complexity. Other items in this chapter provide advice on how to tame the overriding mechanism's complexity while retaining the ability to exploit it as the need arises.