Item 37: Never redefine a function s inherited default parameter value

Item 37: Never redefine a function's inherited default parameter value

Let's simplify this discussion right from the start. There are only two kinds of functions you can inherit: virtual and non-virtual. However, it's always a mistake to redefine an inherited non-virtual function (seeItem 36), so we can safely limit our discussion here to the situation in which you inherit a virtual function with a default parameter value.

That being the case, the justification for this Item becomes quite straightforward: virtual functions are dynamically bound, but default parameter values are statically bound.

What's that? You say the difference between static and dynamic binding has slipped your already overburdened mind? (For the record, static binding is also known as early binding, and dynamic binding is also known as late binding.) Let's review, then.

An object's static type is the type you declare it to have in the program text. Consider this class hierarchy:

 // a class for geometric shapes class Shape { public:   enum ShapeColor { Red, Green, Blue };   // all shapes must offer a function to draw themselves   virtual void draw(ShapeColor color = Red) const = 0;   ... }; class Rectangle: public Shape { public:   // notice the different default parameter value   bad!   virtual void draw(ShapeColor color = Green) const;   ... }; class Circle: public Shape { public:   virtual void draw(ShapeColor color) const;   ... }; 

Graphically, it looks like this:

Now consider these pointers:

 Shape *ps;                       // static type = Shape* Shape *pc = new Circle;          // static type = Shape* Shape *pr = new Rectangle;       // static type = Shape* 

In this example, ps, pc, and pr are all declared to be of type pointer-to-Shape, so they all have that as their static type. Notice that it makes absolutely no difference what they're really pointing to their static type is Shape* regardless.

An object's dynamic type is determined by the type of the object to which it currently refers. That is, its dynamic type indicates how it will behave. In the example above, pc's dynamic type is Circle*, and pr's dynamic type is Rectangle*. As for ps, it doesn't really have a dynamic type, because it doesn't refer to any object (yet).

Dynamic types, as their name suggests, can change as a program runs, typically through assignments:

 ps = pc;                       // ps's dynamic type is                                // now Circle* ps = pr;                       // ps's dynamic type is                                // now Rectangle* 

Virtual functions are dynamically bound, meaning that the particular function called is determined by the dynamic type of the object through which it's invoked:

 pc->draw(Shape::Red);             // calls Circle::draw(Shape::Red) pr->draw(Shape::Red);             // calls Rectangle::draw(Shape::Red) 

This is all old hat, I know; you surely understand virtual functions. The twist comes in when you consider virtual functions with default parameter values, because, as I said above, virtual functions are dynamically bound, but default parameters are statically bound. That means you may end up invoking a virtual function defined in a derived class but using a default parameter value from a base class:

 pr->draw();                       // calls Rectangle::draw(Shape::Red)! 

In this case, pr's dynamic type is Rectangle*, so the Rectangle virtual function is called, just as you would expect. In Rectangle::draw, the default parameter value is Green. Because pr's static type is Shape*, however, the default parameter value for this function call is taken from the Shape class, not the Rectangle class! The result is a call consisting of a strange and almost certainly unanticipated combination of the declarations for draw in both the Shape and Rectangle classes.

The fact that ps, pc, and pr are pointers is of no consequence in this matter. Were they references, the problem would persist. The only important things are that draw is a virtual function, and one of its default parameter values is redefined in a derived class.

Why does C++ insist on acting in this perverse manner? The answer has to do with runtime efficiency. If default parameter values were dynamically bound, compilers would have to come up with a way to determine the appropriate default value(s) for parameters of virtual functions at runtime, which would be slower and more complicated than the current mechanism of determining them during compilation. The decision was made to err on the side of speed and simplicity of implementation, and the result is that you now enjoy execution behavior that is efficient, but, if you fail to heed the advice of this Item, confusing.

That's all well and good, but look what happens if you try to follow this rule and also offer default parameter values to users of both base and derived classes:

 class Shape { public:   enum ShapeColor { Red, Green, Blue };   virtual void draw(ShapeColor color = Red) const = 0;   ... }; class Rectangle: public Shape { public:   virtual void draw(ShapeColor color = Red) const;   ... }; 

Uh oh, code duplication. Worse yet, code duplication with dependencies: if the default parameter value is changed in Shape, all derived classes that repeat it must also be changed. Otherwise they'll end up redefining an inherited default parameter value. What to do?

When you're having trouble making a virtual function behave the way you'd like, it's wise to consider alternative designs, and Item 35 is filled with alternatives to virtual functions. One of the alternatives is the non-virtual interface idiom (NVI idiom): having a public non-virtual function in a base class call a private virtual function that derived classes may redefine. Here, we have the non-virtual function specify the default parameter, while the virtual function does the actual work:

 class Shape { public:   enum ShapeColor { Red, Green, Blue };   void draw(ShapeColor color = Red) const           // now non-virtual   {     doDraw(color);                                  // calls a virtual   }   ... private:   virtual void doDraw(ShapeColor color) const = 0;  // the actual work is };                                                  // done in this func class Rectangle: public Shape { public:   ... private:   virtual void doDraw(ShapeColor color) const;       // note lack of a   ...                                                // default param val. }; 

Because non-virtual functions should never be overridden by derived classes (see Item 36), this design makes clear that the default value for draw's color parameter should always be Red.

Things to Remember

• Never redefine an inherited default parameter value, because default parameter values are statically bound, while virtual functions the only functions you should be overriding are dynamically bound.