Virtual Function During Construction Workaround

Question 1

This is the factory method approach, putting the factory into the base class:

class A {
public:
    virtual void read() = 0;
    template<class X> static X* create() {X* r = new X;X->read();return X;}
    virtual A* clone() const = 0;
};

class B : public A {
    B():A() {   };
    friend class A;
public:
    void read() { /*Do something special for B here.*/ }
    B* clone() const {return new B(*this);}
};

class C : public A {
    C():A() {   };
    friend class A;
public:
    void read() { /*Do something special for C here.*/ }
    C* clone() const {return new C(*this);}
};

Added a clone-method with covariant return type as a bonus.

Using CRTP:

class A {
public:
    // This never needs to be called
    virtual void read() = 0;
    virtual A* clone() const = 0;
};
template<class D, class B> struct CRTP : B {
    D* clone() {return new D(*this);}
    static D* create() {return new D();}
};

class B : public CRTP<B, A> {
    B() {   };
public:
    void read() { /*Do something special for B here.*/ }
};

class C : public CRTP<C, A> {
    C() {   };
public:
    void read() { /*Do something special for C here.*/ }
};

Question 2

The FAQ perspective.

This is a Frequently Asked Question.

See the C++ FAQ item titled “Okay, but is there a way to simulate that behavior as if dynamic binding worked on the this object within my base class's constructor?”.

It’s very often a good idea to check the FAQ (and generally, googling or altavista’ing) before asking.

The question as “Derived class specific base initialization”.

To be clear, while the literal question above is

“What are some work arounds to calling a virtual function during construction?”

it is evident that what’s meant is

“How can a base class B be designed so that each derived class can specify part of what goes on during B construction?”

A major example is where C style GUI functionality is wrapped by C++ classes. Then a general Widget constructor might need to instantiate an API-level widget which, depending on the most derived class, should be a button widget or a listbox widget or whatever. So the most derived class must somehow influence what goes on up in Widget’s constructor.

In other words, we’re talking about derived class specific base construction.

Marshall Cline called that “Dynamic Binding During Construction”, and it’s problematic in C++ because in C++ the dynamic type of an object during class T construction and destruction, is T. This helps with type safety, in that a virtual member function is not called on a derived class sub-object before that sub-object has been initialized, or its initialization has started. But a major cost is that DBDI (apparently) can’t be done in a way that is both simple and safe.

Where the derived class specific init can be performed.

In the question the derived class specific action is called read. Here I call it derived_action. There are 3 main possibilities for where the derived_action is invoked:

Invoked by instantiation code, called two-phase construction.
This essentially implies the possibility of having a mostly unusuable not fully initialized object at hand, a zombie object. However, with C++11 move semantics that has become more common and accepted (and anyway it can be mitigated to some extent by using factories). A main problem is that during the second phase of construction the ordinary C++ protection against virtual calls on uninitialized sub-objects, due to dynamic type changes during construction, is not present.
Invoked by Derived constructor.
For example, derived_action can be invoked as an argument expression for the Base constructor. A not totally uncommon technique is to use a class template to generate most derived classes that e.g. supply calls of derived_action.
Invoked by Base constructor.
This implies that knowledge of derived_action must be passed up to the constructor, dynamically or statically. A nice way is to use a defaulted constructor argument. This leads to the notion of a parallel class hierarchy, a hierarchy of derived class actions.

This list is in order of increasing sophistication and type safety, and also, to the best of my knowledge, reflects the historical use of the various techniques.

E.g. in Microsoft’s MFC and Borland’s ObjectWindows GUI early 1990’ libraries two-phase construction was common, and that kind of design is now, as of 2014, regarded as very ungood.

Question 3

One way to achieve this, would be simply to delegate it to another class (that is perhaps a friend) and can be sure to be called when fully constructed.

class A
{
friend class C;
private:
    C& _c; // this is the actual class!    
public:
    A(C& c) : _c(c) { };
    virtual ~A() { };
    virtual void read() = 0;
};


class B : public A
{
public:
    B(C& c) : A(c) { };
    virtual ~B() { };

    virtual void read() { 
       // actual implementation
    };
};


class C
{
private:
    std::unique_ptr<A> _a;

public:
    C() : _a(new B(*this)) { // looks dangerous?  not at this point...
        _a->read(); // safe now
    };
};

In this example, I just create a B, but how you do that can depend on what you want to achieve and use templates on C if necessary, e.g:

template<typename VIRTUAL>
class C 
{
private:
   using Ptr = std::unique_ptr<VIRTUAL>;

   Ptr _ptr;
public:
   C() : _ptr(new VIRTUAL(*this)) {
       _ptr->read();
   };
}; // eo class C

Question 4

The workaround is to call the virtual function after construction. You can then couple the two operations (construction + virtual call) in factory function. Here is the basic idea:

class FactoryA
{
public:
    A *MakeA() const
    {
        A *ptr = CreateA();
        ptr->read();
        return ptr;
    }

    virtual ~FactoryA() {}

private:
    virtual A *CreateA() const = 0;
};

class FactoryB : public FactoryA
{
private:
    virtual A *CreateA() const { return new B; }
};

// client code:

void f(FactoryA &factory)
{
    A *ptr = factory.MakeA();
}

Question 5

As mentioned by Benjamin Bannier, you can use CRTP (a template which defines the actual read() function.) One problem with that method is that templates have to always be written inline. That can at times be problematic, especially if you are to write really large functions.

Another way is to pass a function pointer to the constructor. Although, in a way, it is similar to calling the function in your constructor, it forces you to pass a pointer (although in C++ you could always pass nullptr.)

class A
{
public:
    A(func_t f)
    {
        // if(!f) throw ...;
        (*f)();
    }
};

class B : A
{
public:
    B() : A(read) {}

    void read() { ... }
};

Obviously, you have the "can't call other virtual functions" problem within the read() function and any function it calls. Plus, variable members of B are NOT yet initialized. That is probably a much worst problem in this case...

For that reason, writing it this way is safer:

   B() : A()
   {
       read();
   }

However, in cases like that, that may be the time when you an some for of init() function. That init() function can be implemented in A() (if you make it accessible: i.e. use public A when deriving) and that function can call all the virtual functions as expected:

class A
{
public:
    void init()
    {
        read();
    }
};

class B : public A
{
public:
    ...
};

I know a lot of people say that an init() function is evil because people who create a B object now need to know to call it... but there isn't much else you can do. That being said, you could have a form of factory, and that factory can do the init() call as required.

class B : public A
{
public:
    static B *create() { B *b(new B); b->init(); return b; }

private:
    B() { ... } // prevent creation without calling create()
};