Calling virtual functions inside constructors

Question

Suppose I have two C++ classes:

class A
{
public:
  A() { fn(); }

  virtual void fn() { _n = 1; }
  int getn() { return _n; }

protected:
  int _n;
};

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

  virtual void fn() { _n = 2; }
};

If I write the following code:

int main()
{
  B b;
  int n = b.getn();
}

One might expect that n is set to 2.

It turns out that n is set to 1. Why?

Solution 1

Calling virtual functions from a constructor or destructor is dangerous and should be avoided whenever possible. All C++ implementations should call the version of the function defined at the level of the hierarchy in the current constructor and no further.

The C++ FAQ Lite covers this in section 23.7 in pretty good detail. I suggest reading that (and the rest of the FAQ) for a followup.

Excerpt:

[...] 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”.

[...]

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.

EDIT Corrected Most to All (thanks litb)

Solution 2

Calling a polymorphic function from a constructor is a recipe for disaster in most OO languages. Different languages will perform differently when this situation is encountered.

The basic problem is that in all languages the Base type(s) must be constructed previous to the Derived type. Now, the problem is what does it mean to call a polymorphic method from the constructor. What do you expect it to behave like? There are two approaches: call the method at the Base level (C++ style) or call the polymorphic method on an unconstructed object at the bottom of the hierarchy (Java way).

In C++ the Base class will build its version of the virtual method table prior to entering its own construction. At this point a call to the virtual method will end up calling the Base version of the method or producing a pure virtual method called in case it has no implementation at that level of the hierarchy. After the Base has been fully constructed, the compiler will start building the Derived class, and it will override the method pointers to point to the implementations in the next level of the hierarchy.

class Base {
public:
   Base() { f(); }
   virtual void f() { std::cout << "Base" << std::endl; } 
};
class Derived : public Base
{
public:
   Derived() : Base() {}
   virtual void f() { std::cout << "Derived" << std::endl; }
};
int main() {
   Derived d;
}
// outputs: "Base" as the vtable still points to Base::f() when Base::Base() is run

In Java, the compiler will build the virtual table equivalent at the very first step of construction, prior to entering the Base constructor or Derived constructor. The implications are different (and to my likings more dangerous). If the base class constructor calls a method that is overriden in the derived class the call will actually be handled at the derived level calling a method on an unconstructed object, yielding unexpected results. All attributes of the derived class that are initialized inside the constructor block are yet uninitialized, including 'final' attributes. Elements that have a default value defined at the class level will have that value.

public class Base {
   public Base() { polymorphic(); }
   public void polymorphic() { 
      System.out.println( "Base" );
   }
}
public class Derived extends Base
{
   final int x;
   public Derived( int value ) {
      x = value;
      polymorphic();
   }
   public void polymorphic() {
      System.out.println( "Derived: " + x ); 
   }
   public static void main( String args[] ) {
      Derived d = new Derived( 5 );
   }
}
// outputs: Derived 0
//          Derived 5
// ... so much for final attributes never changing :P

As you see, calling a polymorphic (virtual in C++ terminology) methods is a common source of errors. In C++, at least you have the guarantee that it will never call a method on a yet unconstructed object...

Solution 3

The reason is that C++ objects are constructed like onions, from the inside out. Base classes are constructed before derived classes. So, before a B can be made, an A must be made. When A's constructor is called, it's not a B yet, so the virtual function table still has the entry for A's copy of fn().

Solution 4

The C++ FAQ Lite Covers this pretty well:

Essentially, during the call to the base classes constructor, the object is not yet of the derived type and thus the base type's implementation of the virtual function is called and not the derived type's.

Solution 5

One solution to your problem is using factory methods to create your object.

• Define a common base class for your class hierarchy containing a virtual method afterConstruction():

class Object
{
public:
  virtual void afterConstruction() {}
  // ...
};

• Define a factory method:

template< class C >
C* factoryNew()
{
  C* pObject = new C();
  pObject->afterConstruction();

  return pObject;
}

• Use it like this:

class MyClass : public Object 
{
public:
  virtual void afterConstruction()
  {
    // do something.
  }
  // ...
};

MyClass* pMyObject = factoryNew();

View more solutions

Comments

[David Coufal]

I'm asking and answering my own question because I want to get the explanation for this bit of C++ esoterica into Stack Overflow. A version of this issue has struck our development team twice, so I'm guessing this info might be of use to someone out there. Please write out an answer if you can explain it in a different/better way...

[Venedictos]

I'm wondering why this got down voted? When I first learned C++ this really confused me. +1

[Craig Reynolds]

What surprises me is the lack of a compiler warning. The compiler substitutes a call to the “function defined in the class of the current constructor” for what would in any other case be the “most overridden” function in a derived class. If the compiler said “substituting Base::foo() for call to virtual function foo() in constructor” then the programmer would be warned that the code will not do what they expected. That would be a lot more helpful than making a silent substitution, leading to mysterious behavior, lots of debugging, and eventually a trip to stackoverflow for enlightenment.

[user207421]

@CraigReynolds Not necessarily. There is no need for special compiler treatment of virtual calls inside constructors The base class constructor creates the vtable for the current class only, so at that point the compiler can just call the vitrual function via that vtable in exactly the same way as usual. But the vtable doesn't point to any function in any derived class yet. The vtable for the derived class is adjusted by the derived class's constructor after the base class constructor returns, which is how the override will work once the derived class is constructed.

[Admin]

C++ does not normally use the term "super class" - it prefers "base class".

[Kevin]

I wish I could upvote this 100 times. Doing such things usually indicates flawed design.

[David Rodríguez - dribeas]

That is the same in most OO languages: you cannot possibly build a derived object without the base part being already constructed.

[Johannes Schaub - litb]

Not most C++ implementations, but all C++ implementations have to call the current class's version. If some don't, then those have a bug :). I still agree with you that it's bad to call a virtual function from a base class - but semantics are precisely defined.

[curiousguy]

"Calling a virtual function in this situation may work but is not guaranteed" That is not correct. The behaviour is guaranteed.

[DS.]

Good job explaining why the alternative is (also) are error-prone.

[Arek Bal]

"If the base class constructor calls a method that is overriden in the derived class the call will actually be handled at the derived level calling a method on an unconstructed object..." How so if base is already initialized. There is no possiblity unless you explicilty call "init" before initializing other members.

[Ciro Santilli OurBigBook.com]

And the following FAQ page discusses exactly how to work around it.

[Steven Sudit]

It's not dangerous, it's just non-virtual. In fact, if methods called from the constructor were called virtually, it would be dangerous because the method could access uninitialized members.

[Siyuan Ren]

Why is calling virtual functions from destructor dangerous? Isn't the object still complete when destructor runs, and only destroyed after the destructor finishes?

[The_Sympathizer]

@Kevin: So what alternative designs should one use in a situation where one may be tempted to do this? (In the case where I considered this, I had the problem of initializing a data field in the base differently depending on the derived type)

[Wolf]

Your are talking of Calling virtual functions on the same object from a constructor or destructor. This is clear to me, but in your spelling this can lead to misunderstandings.

[M.M]

@DavidRodríguez-dribeas other languages do actually do that. For example in Pascal, memory is allocated for the whole object first, but then only the most-derived constructor is invoked. A constructor must either contain an explicit call to its parent's constructor (which does not have to be the first action - it just has to be somewhere), or if it doesn't , it's as if the first line of the constructor made that call.

[underscore_d]

This is awfully highly voted for not explaining why and basically amounting to a link-only answer. (and a link to that notorious moving target of the C++ FAQ... well, moving in terms of URLs, if not up-to-date content!)

[underscore_d]

An explanation! +1, superior answer imho

[underscore_d]

The question is why b's constructor calls the base f(), not the derived override of it. Type of the variable b is irrelevant to that.

[underscore_d]

@curiousguy ...guaranteed to call the base version if available, or to invoke UB if the vfunc is pure virtual.

[curiousguy]

The vptr isn't changed at the end of the ctor. In the body of ctor C::C, virtual function calls go the C overrider, not to any base class version.

[curiousguy]

The dynamic type of the object is defined after the ctor has called base class ctors and before it constructs its members. So the vptr isn't changed at the end of the ctor.

[Cheers and hth. - Alf]

−1 "is dangerous", no, it's dangerous in Java, where downcalls can happen; the C++ rules remove the danger through a pretty expensive mechanism.

[Lightness Races in Orbit]

In what way is calling a virtual function from a constructor "dangerous"? This is total nonsense.

[Lightness Races in Orbit]

"The function calls would not reference the vtable" That is not true. If you think virtual dispatch is only enabled when accessing through a B* or ` B&`, you are mistaken.

[VinGarcia]

For me the problem is that there are so many restrictions in C++ classes that its incredible hard to achieve any good design. C++ dictates that "If it could be dangerous forbid it" even if its intuitive causing problems such as: "Why this intuitive behavior doesn't work" to happen all the time.

[user5193682]

Thanks for the clarity and avoidance of details which doesnt go straight to the outcome

[moodboom]

Clear, straightforward, simplest answer. It's still a feature I would love to see get some love. I hate having to write all these silly initializeObject() functions that the user is forced to call right after the construction, just bad form for a very common use case. I understand the difficulty though. C'est la vie.

[Pablo H]

@SiyuanRen No, the object is not complete anymore. When a destructor runs, derived clases' destructors for the same object have already run and finished. So derived classes' invariants are (potentially) no longer valid, and running a derived-class member would be (potentially) dangerous. The same as with constructors, but in reverse order.

[underscore_d]

All C++ implementations should => All conforming C++ implementations will. "Should" is too charitable. The language requires, not recommends, this.

[underscore_d]

@VinGarcia What? C++ does not "forbid" anything in this case. The call is simply treated as a non-virtual call, to the method for the class whose constructor is currently executing. That is a logical consequence of the object construction timeline - not some draconian decision to stop you doing silly things. The fact that it coincidentally fulfills the latter purpose too is just a bonus to me.

[underscore_d]

@moodboom What "love" do you propose? Bear in mind that you can't just change how things currently work in-place, because that would horribly break reams of existing code. So, how would you do it instead? Not only what new syntax you would introduce to allow (actual, non-devirtualised) virtual calls in constructors - but also how you would somehow amend the models of object construction/lifetime so that those calls would have a complete object of the derived type on which to run. This'll be interesting.

[underscore_d]

It's hard to see how this is the same problem, as you didn't explain why. Calls to non-pure virtual functions during ctors are perfectly legal, but they just don't go through the (not yet constructed) virtual table, so the version of the method that gets executed is the one defined for the class type whose ctor we are in. So those don't crash. This one does because it's pure virtual and unimplemented (side note: one can implement pure virtual functions in the base), so there is no version of the method to be called for this class type, & the compiler assumes you don't write bad code, so boom

[moodboom]

@underscore_d I don't think any syntax changes would be needed. Maybe when creating an object, the compiler would add code to walk the vtable and look for this case and patch things then? I've never written a C++ compiler and I'm quite sure my initial comment to give this some "love" was naive and this will never happen. :-) A virtual initialize() function isn't a very painful workaround anyway, you just have to remember to call it after creating your object.

[moodboom]

@underscore_d I just noticed your other comment below, explaining that the vtable isn't available in constructor, emphasizing again the difficulty here.

[underscore_d]

D'oh. The calls do go through the vtable, but it hasn't yet been updated to point at the overrides for the most-derived class: only the one being constructed right now. Still, the result and reason for the crash remains the same.

[underscore_d]

@moodboom Syntax changes are needed to avoid breaking existing code that assumes, per all Standards to date, that a ctor calling a virtual method calls the constructing class's override, not the most derived one. Such calls aren't desirable, so we all try to avoid them & wince when we end up (ideally temporarily) using one. But they get into code. Such code expects that behaviour, & if the language starts calling the most-derived override instead, the code breaks (certainly in theory, very possibly in practice). So, even if possible, this cannot be adopted without explicit, different syntax.

[underscore_d]

@moodboom I goofed when writing about the vtable not being available in the constructor. It is available, but the constructor only sees the vtable for its own class, because each derived constructor updates the instance's vptr to point at the vtable for the current derived type and no further. So, the current ctor sees a vtable that only has its own overrides, hence why it can't call any more-derived implementations of any virtual functions.

[moodboom]

@underscore_d makes sense, thanks. And regarding standards changes, totally agree. Any standards change has to consider the massive existing codebase, and this concept would be disruptive.

[moodboom]

Just for fun... Maybe you could add three colons base:::function() to get super-virtualized behavior? :-)

[underscore_d]

Aside from the fact that it follows its own logic to the wrong conclusion... The idea behind this answer, known static type, is misapplied. A compiler could devirtualise b.getN() because it knows the real type, & just directly dispatch to the version from B. But that's just an allowance made by the as-if rule. Everything still must act as-if the virtual table is used & followed to the letter. In the A constructor, the same is true: even if (probably not possible) it gets inlined w/ the B ctor, the virtual call must still act as-if it only has the base A vtable available to use.

[VinGarcia]

Yeah, its a logical consequence of the internal implementation. My point is it is unexpected. C++ have too many of these cases and do not protect the user from any (by protection I mean making it hard or impossible to achieve an unexpected result). About "forbid" ok it does not forbid, in most cases, it just crashes which is actually worse. I know it is a language designed a long time ago with complicated efficiency constraints but it is still a design problem. Checkout rust programming language for a counter example.

[underscore_d]

@VinGarcia It's only "unexpected" to people who don't bother to actually learn how the language works before using it, and instead just assume their expectations will reflect reality without checking - in which case, I have no sympathy: languages, by definition, are something that you learn, not "expect". I contend that, as a design decision, it is clearly documented and makes perfect sense. And I don't want to use another language, though you didn't explain why it makes a relevant counterexample anyway.

[Picaud Vincent]

Now with C++11, a possible safeguard is to add the "final" keyword to any class that uses virtual methods in its constructor. This prevents from the mentioned problem and legitimate this technique that can be useful in some circumstances. Obviously a side effect is that you can not inherit this class anymore. nb: only tagging as "final" the involved virtual method is not enough for 100% security because this method can still call another, yet undefined, virtual methods.

[Yogesh]

@curiousguy I am saying the same thing, that vptr is not changed at the end of constructor of base class, it will be changed at the end of constructor of derived class. I hope you are telling the same. Its an compiler/implementation dependent thing. When are you proposing that vptr should change. Any good reason for downvoting?

[curiousguy]

The timing of the change of vptr is not implementation dependent. It is prescribed by language semantics: the vptr changes when the dynamic behavior of the class instance changes. There is no freedom here. Inside the body of a ctor T::T(params), the dynamic type is T. The vptr will reflect that: it will point to vtable for T. Do you disagree?

[curiousguy]

Maybe it would easier to have a real example of inheritance to talk about

[Dominic Farolino]

I noticed "In C++ the Base class will build its version of the virtual method table prior to entering its own construction" - does this mean on the contrary, the Derived class's virtual table does not get constructed until it's own construction completes?

[Wang]

I think I will avoid to do this. This is not single Base class any more. You actually created lots of different Base class.

[Peter - Reinstate Monica]

@LightnessRacesinOrbit Can you give me an example for your assertion that virtual dispatch happens without calling through a reference or pointer (including the implicit this)?

[Peter - Reinstate Monica]

@user2305329 You are right that the call b.getn() is non-virtual. b is a statically typed object, and whatever getn() is defined for its type will be called. But inside member functions, including the constructor, all member function calls are made through the implicit this pointer and are hence virtual function calls, if it is a polymorphic class. The reason and rationale for resolving the virtual fn() call to the base class's implementation -- even though it happens during the overall construction of a derived object -- is explained in the other answers.

[Lightness Races in Orbit]

@PeterA.Schneider "including the implicit this" That's the case I seemed to believe the author was missing

[curiousguy]

@Wang Exactly: Base<T> is just a helper class, not a common interface type that can be used for runtime polymorphism (f.ex. heterogeneous containers). These are useful too, just not for the same tasks. Some classes inherit both from a base class that's an interface type for runtime polymorphism and another that's a compile time template helper.

[Raj]

type need to specify for template function MyClass* pMyObject = factoryNew<MyClass>();

[user207421]

@PabloH That is the exact opposite of the truth. When a destructor body runs, the base class's destructor has already run. The derived class's denstructor doesn't run until this constructor has exited.

[user207421]

@underscore_d It's not treated as a non-virtual call. It's treated the same as any other virtual call. The point is that within the constructor the vtable doesn't point to any derived class's overridden methods yet, so the virtual call can't 'see' beyond the current class scope.

[Pablo H]

@user207421 No, what I wrote is the mandated behaviour. E.g. n3797 draft for C++11 states in 12.4.8 [class.dtor] that "After executing the body of the destructor [...], a destructor for class X calls [...] the destructors for X’s direct base classes [...]. Bases and members are destroyed in the reverse order of the completion of their constructor (see 12.6.2)."

[ivan.ukr]

But how compiler does this technically? Sets vptr to the address of vtable for the current class?

[BAKE ZQ]

@ivan.ukr In book c++ data model, the author said the setting of vptr is inserted before the codes written by user, so folling the contruction call, firstly set to the base class's vtable, then the derived class'.

[BAKE ZQ]

Can anyone tell me if the calling still uses the vptr(since the vptr is set to the current level) way or just statically calls the version of the current level.

[BAKE ZQ]

If the calling still uses the vptr(since the vptr is set to the current level as you metioned too) way or just statically calls the version of the current level.

[uwydoc]

this approach is cannot be extended, what if we need another class that inherit Derived and provide its own Name impl. the CRTP solution posted by @stands2reason is actually the defacto solution

[Tomer Shetah]

Hello and welcome to SO! Please read the tour, and How do I write a good answer? For example adding a code snippet might help.

[Davis Herring]

@BAKEZQ: It’s the vptr one, since it works even if the call occurs in a function called from the constructor/destructor. Direct calls may of course be optimized just like any other devirtualization.

[Don Slowik]

You can track how it changes as I did above.

[Don Slowik]

To the extent a virtual override in Derived touches its data members, that 3rd paragraph also illustrates the danger if calls to virtuals behaved as in OPs ‘might expect that..‘alternative.

[François Andrieux]

This solution has undefined behavior. sleep_for does not synchronize threads, so you have a race on this->Print() both during construction and destruction. Second, this risks crashing as the worker requires this to still exist (it is a member function) but there is no guarantee of that. If you don't have an arbitrary wait like getchar() the Sub instance can easily reach the end of its lifetime before the thread prints. Solutions that rely on detach() are almost always broken.

[user2943111]

@underscore_d "(side note: one can implement pure virtual functions in the base)" No you can not, otherwise the method is no longer pure virtual. You also can not make instances of an abstract class, so the example by TimW will not compile if you try to call a pure method from the constructor. It now compiles because the constructor does not call pure virtual methods and contains no code, just a comment.