intermediate class: pure virtual method called

Question

For many classes C1, C2, and so forth, the initialization looks equal, and it's just a little something differs from class to class. Hence I created a base class B that hosts the initalizations, e.g.:

class B {
  public:
    B()
    {
      // complex initializations
      int a = doSomething();
      // more complex stuff with `a`
    };

    virtual int doSomething()
    {return 2 * doSomethingHelper();}

  protected:
    virtual int doSomethingHelper() = 0;
};

class C: public B {
  protected:
    virtual int doSomethingHelper()
    {return 1;}
};

int main() {
  C c;
  return 0;
}

This code fails with

pure virtual method called
terminate called without an active exception
Aborted (core dumped)

since doSomethingHelper() is used to initialize B.

I'm wondering if there is a better design. My objectives are:

1. Make C's user interface as easy as possible: C has no constructor arguments.

2. Make C itself as minimalistic as possible such that other concretizations of B are short. Ideally, it only contains the doSomethingHelper.

A suggestion for a more sane design would be appreciated.

Answer 1

According to the standard:

10.4/6: Member functions can be called from a constructor (or destructor) of an abstract class; the effect of making a virtual call (10.3) to a pure virtual function directly or indirectly for the object being created (or destroyed) from such a constructor (or destructor) is undefined

This is because, when you construct C:

• first the subobject B is constructed using the B() constructor. At that time, it's still B's virtual functions which are used. You get the error because at this moment, doSomethingHelper() is not defined for it.

• Only once B() is completed will the virtual will C's virtual functions become active.

Two phased initialisation

This situation can only be avoided through a two phased initialisation: first construction, then calling an initialisation function. Not so nice and user friendly as you'd have desired.

class B {
public:
    B() { /* complex initializations */ }
    ...
protected:
    void init() {  //  the rest of the what you wanted in constructor 
        int a = doSomething();
        // more complex stuff with `a`
    }
};

The two phased initialisation could then be triggered via C's constructor:

class C {
public: 
    C() : B() {  // first B is constructed
       init();   // then the body of C's constructor is executed
    }   
 ...
 };

Variant for the two-phased initialisation

There's a small variant that you can use, to hide the two phase approach, and let more freedom for the user about defining or not their own constructor.

In B you define an auxiliary nested class:

protected:
    class initialiser {
    public: 
        initialiser(B*b) {b->init();}  // the constructor launches the second phase init
    };

In C , you just need to add a protected member variable:

class C:  public  B {
    ...
protected:
    B::initialiser bi{this}; // this triggers automaticcaly the second phase
    ...
};

The standard's rules ensure that first B is constructed and then the members of C. Demo here.

Answer 2

Short answer:

Don't call virtual functions from within a constructor. Doing so will get you in trouble.

Longer answer:

The declaration C c creates and constructs, in steps, an instance of class C. That object is first constructed as a class A object, then as a class B object, and finally as a class C object. At the point that B::B() is called, there is no notion that the object will eventually be an instance of class C.

When B::B() is invoked, it calls the virtual function doSomething(), which in this case means calling B::doSomething(). There's no problem yet; that function exists. The problem is with the call to doSomethingHelper() within the body of B::doSomething(). That function is pure virtual at this point. As noted above, there is no indication that this object will eventually be an instance of class C. The function C::doSomethingHelper() cannot be called cannot be called from B::B() or A::A(). There is no A::doSomethingHelper(), no B::doSomethingHelper(), so the function doesn't exist. You're toast.

I'm wondering if there is a better design.

There are lots of better designs. The simplest is to not call doSomething() from within the constructor of class B. Move that call to the constructor of class C. Even then, calling a virtual function from within the constructor may not be a good idea. What if class D inherits from class C and overrides C::doSomethingHelper()? An instance of class D will be constructed by calling C::doSomethingHelper() rather than D::doSomethingHelper().

Answer 3

You can't use dynamic dispatching to a derived class in a constructor.

When B's constructor is running, the C subobject has not yet been created, so none of its overriden functions can be used. As B doesn't provide an implementation for doSomethingHelper, nothing sensible can be done.

Answer 4

Move all the complexity into B::doSomething, and call that method from the end of inheritance chain, C:

class B {
  public:
    B()
    {};

    virtual int doSomething()
    {
      // complex initializations
      int a = 2 * doSomethingHelper();
      // more complex stuff with `a`
      return a;
    }

  protected:
    virtual int doSomethingHelper() = 0;
};

class C: public B {
  public:
    C(): B()
    {
      int a = doSomething();
    }

  protected:
    virtual int doSomethingHelper()
    {return 1;}
};

int main() {
  C c;
  return 0;
}

This might require you to make some of B formerly private members protected such that they can be initialized by C.