Calling a virtual function from the constructor [duplicate]

Question

I'm reading Effective C++, and there is the "Item 9: Never call virtual functions during construction or destruction". And I'm wondering if my code is fine even if it breaks this rule:

using namespace std;

class A{
    public:
        A(bool doLog){
            if(doLog)
               log();
        }

        virtual void log(){
            cout << "logging A\n";
        }
};


class B: public A{
public:
    B(bool doLog) : A(false){
        if(doLog)
            log();
    }

    virtual void log(){
        cout << "logging B\n";
    }
};


int main() {
    A a(true);
    B b(true);
}

Is there something wrong with this approach? May I get in trouble when I do something more complicated?

It seams to me that most answers didn't get what I did there, and they simply explained again why is calling virtual function from constructor potentially dangerous.

I would like to stress out that output of my program looks like this:

logging A
logging B

So I get A logged when it is constructed and B logged when it is constructed. And that is what I want! But I'm asking if You find anything wrong(potentially dangerous) with my "hack" to overcome the problem with calling virtual function in constructor.

Wineglass

In this case you patched it up fine, but if other people need to use that code mistakes are bound to happen. – Influence

@JoachimPileborg this is not true: the behaviour is defined. During construction, virtual function calls are disabled (e.g. the implementation of the currently-constructing type is used). – Influence

Answer 1

And I'm wondering if mine code is fine even if it breaks this rule:

It depends on what you mean by "fine". Your program is well-formed, and its behavior is well-defined, so it won't invoke undefined behavior and stuff like that.

However, one may expect, when seeing a call to a virtual function, that the call is resolved by invoking the implementation provided by the most derived type which overrides that function.

Except that during construction, the corresponding sub-object has not been constructed yet, so the most derived subobject is the one currently being constructed. Result: the call is dispatched as if the function were not virtual.

This is counter-intuitive, and your program should not rely on this behavior. Therefore, as a literate programmer, you should get used to avoid such a pattern and follow Scott Meyer's guideline.

Subarid

Nicely explained, but I have to say I find it very intuitive. I programmed in C++ for years and when later I discovered languages which did call the most derived classes version I was shocked and appalled. – Pate

Answer 2

Is there something wrong with this approach?

Answer from Bjarne Stroustrup:

Can I call a virtual function from a constructor?

Yes, but be careful. It may not do what you expect. In a constructor, the virtual call mechanism is disabled because overriding from derived classes hasn't yet happened. Objects are constructed from the base up, "base before derived". Consider:

    #include<string>
    #include<iostream>
    using namespace std;

class B {
public:
    B(const string& ss) { cout << "B constructor\n"; f(ss); }
    virtual void f(const string&) { cout << "B::f\n";}
};

class D : public B {
public:
    D(const string & ss) :B(ss) { cout << "D constructor\n";}
    void f(const string& ss) { cout << "D::f\n"; s = ss; }
private:
    string s;
};

int main()
{
    D d("Hello");
}

the program compiles and produce

B constructor
B::f
D constructor

Note not D::f. Consider what would happen if the rule were different so that D::f() was called from B::B(): Because the constructor D::D() hadn't yet been run, D::f() would try to assign its argument to an uninitialized string s. The result would most likely be an immediate crash. Destruction is done "derived class before base class", so virtual functions behave as in constructors: Only the local definitions are used - and no calls are made to overriding functions to avoid touching the (now destroyed) derived class part of the object.

For more details see D&E 13.2.4.2 or TC++PL3 15.4.3.

It has been suggested that this rule is an implementation artifact. It is not so. In fact, it would be noticeably easier to implement the unsafe rule of calling virtual functions from constructors exactly as from other functions. However, that would imply that no virtual function could be written to rely on invariants established by base classes. That would be a terrible mess.

Extenuatory

Answer 3

It's "fine" in the sense of being well-defined. It may not be "fine" in the sense of doing what you expect.

You will call the override from the class currently being constructed (or destroyed), not the final override; since the final derived class has not yet been constructed (or has already been destroyed) and so can't be accessed. So you may get in trouble if you wanted the final override to be called here.

Since this behaviour is potentially confusing, it's best to avoid having to do it. I would recommend adding behaviour to a class by aggregation rather than subclassing in that situation; the class members are constructed before the constructor body, and last until after the destructor, and so are available in both those places.

One thing you mustn't do is call a virtual function from the constructor or destructor if it's pure virtual in that class; that's undefined behaviour.

Trotyl