Gotcha #75: Calling Virtual Functions in Constructors and Destructors

Constructors are used to seize resources an object needs to perform its operations, and destructors are used to free those resources. Why don't we just make that architectural decision explicit in the design of our base class?

class B { 


 public:


   B() { seize(); }


   virtual ~B() { release(); }


 protected:


   virtual void seize() {}


   virtual void release() {}


};

Derived classes can then override the base class seize and release functions to customize their resource-acquisition behavior:

class D : public B { 


 public:


   D() {}


   ~D() {}


   void seize() {


       B::seize(); // get base resources


       // get derived resources . . .


   }


   void release() {


       // release derived resources . . .


       B::release(); // release base resources


   }


};


// . . .


D x; // no resources seized or released!

As the first step in the initialization of x, the derived class constructor invokes the base class constructor, which in turn makes a virtual function call to seize. As the last step in the destruction of x, the derived class destructor invokes the base class destructor, which in turn makes a virtual call to release. However, no resources are seized or released.

The problem is that, at the point the base class constructor is invoked from the derived class constructor, the object x is not yet of type D. The base class constructor initializes the B subobject within x to behave like a B object. Therefore, when the virtual seize function is called, it binds to B::seize. The same situation occurs in reverse on destruction. When the derived class destructor invokes the base class destructor, the object x is no longer of type D, and the B subobject of x will behave like a B object. The virtual function call of release will bind to B::release.

In this case, the simplest solution would be the built-in mechanism for implementing construction and destruction of complex objects. The code that seizes and releases resources for base class subobjects should be present in the constructors and destructors:

class B { 


 public:


   B() {


       // get base resources . . .


   }


   virtual ~B() {


       // release base resources . . .


   }


};


class D : public B {


 public:


   D() {


       // get derived resources . . .


   }


   ~D() {


       // release derived resources . . .


   }


};


// . . .


D x; // works!

By the way, this is one way it's sometimes possible to call a pure virtual function with a virtual, rather than static, calling sequence:

class Abstract { 


 public:


   Abstract();


   Abstract( const Abstract & );


   virtual bool validate() const = 0;


   // . . .


};


bool Abstract::validate() const


   { return true; }


Abstract::Abstract() {


   if( validate() ) // attempt to call pure virtual


       // . . .


};

However, the standard specifies that the behavior of such a call is undefined. Typical observed behaviors on specific platforms include making a virtual call to a function that simply aborts, attempting to call a function through a null pointer to function, or (this is the dangerous one) actually calling Abstract::validate. Even if this is desired behavior, such code is fragile and unportable.

Note that this gotcha deals only with the invocation of a virtual function on an object currently under construction or destruction. It's perfectly reasonable for a constructor or destructor to call a virtual function of another, fully constructed object:

Abstract::Abstract( const Abstract &that ) { 


   if( that.validate() ) // OK


       // . . .


}