Calling pure virtual function [duplicate]

Question

Possible Duplicate:
Calling virtual functions inside constructors

Look at this code. In the constructor of Base class, we can call the pure virtual function using 'this' pointer. Now when I want to create a typed pointer to the same class and casting 'this' to the same type. It throws run time exception 'pure virtual function call exception'. Why is this so ?

#include <iostream>

using namespace std;

class Base
{
  private:
  virtual void foo() = 0;
  public:
  Base()
  {
    //Uncomment below 2 lines and it doesn't work (run time exception)
    //Base * bptr = (Base*)this;
    //bptr->foo();
    //This call works
    this->foo();
  }
};

void
Base::foo()
{
  cout << "Base::foo()=0" << endl;
}

class Der : public Base
{
  public:
  Der()
  {
  }
  public:
  void foo()
  {
    cout << "Der::foo()" << endl;
  }
};

int main()
{
  cout << "Hello World!" << endl;
  Der d;
}

Selfpollination

This question is not a duplicate. Here the question is specifically why this->foo() works whereas calling via the cast fails. – Buckish

Answer 1

You must never call virtual functions within a constructor.

Virtual functions don't get dispatched the way you think they do. Rather, during construction, the dynamic type of the base subobject that is being constructed is the base type, and thus the function is dispatched to the base function (which is pure-virtual in your case).

Just don't do it.

(The reason is obvious: When constructing a derived object, the base subobject must necessarily be constructed first, so the ambient derived object doesn't even exist at the time of the base construction.)

---

Edit: Here's some more explanation. Compilers are perfectly allowed and encouraged to perform virtual dispatch statically if they can do so. In that case, it is determined at compile time already which actual function will be called. This happens when you say foo() or this->foo() in the Base constructor, or when you say x.Base::foo() in some other context where Derived x; is your object. When the dispatch happens statically, then either the implementation of Base::foo() is called directly, or you get a linker error if there is no implementation.

On the other hand, if the dispatch happens dynamically, i.e. at runtime, then there is a possibility, albeit unusual, that the dispatch actually ends up picking Base::foo() as the final target. This cannot happen under "normal" conditions, because the compiler won't let you instantiate a class with pure-virtual functions, and so the target of an ordinary dynamic dispatch is always a function for which an implementation must exist (or at least you'd get a linker error if you don't link it).

But there is one more situation, which is the one in question: The compiler decides to perform the dispatch at runtime, for whatever reason, and the dipatch ends at a pure-virtual function. In that case your program terminates. It is irrelevant whether the function is implemented or not, but is simply doesn't have an entry in the polymorphic class hierarchy (think of it as a "null pointer in the vtable", hence the = 0). For this to happen, the dynamic type of the object must be the type of an abstract base class, and the dispatch has to happen dynamically. The former can only be achieved inside the base constructor of a derived object, and the latter requires you to convince the compiler not to dispatch the call statically. This is where the difference between this->foo() (static) and Base * p = this; p->foo(); (dynamic) comes in. (Also contrast this to x.Base::foo(), which is dispatched statically.)

All this is merely a consequence of the implementation and covered by the blanket "undefined behaviour", of course. If you want to take one thing away from it, then it is that dynamic dispatch cannot find a pure-virtual function. And of course that you must never call virtual functions within a constructor.

Concent

You may want to add a link to artima.com/cppsource/nevercall.html – Verbalism

It is perfectly fine to call virtual functions in constructor as long as one knows how they work. So never is a bit harsh.In this case the function being called is a pure virtual function & calling pure virtual function in a constructor is UB. – Flier

You may call a virtual function as long as it is not a pure virtual function, and as long as you know that what you are calling is the method from the class itself and not expecting any polymorphism. Calling a pure virtual function from a constructor is undefined behaviour even if it has an implementation. – Fifi

I do agree with the reason that we shouldn't use it. Still I am curious to know why this calls the pure virtual function whereas the pointer to same class isn't ? What is the factor which is used by the compiler to decide it ? It is not compile time error though. – Selfpollination

@siddhusingh: This is what happens: When you construct a derived class D that inherits from B then the first thing that happens is that the B-subobject is constructed, which ends with a constructor of B running. At that time, the type of this, inside the B constructor, is B*. Next, all the members of D are constructed, and only then is the body of a D constructor executed, and only at that time the type of this is D*. If you call a non-pure virtual inside the B-constructor, you simply end up dispatching to the implementation of B. – Concent

@KerrekSB: I fully agree with your point. My question is yet not answered. When I am calling the pure virtual function(defined in B only) in class B's constructor using 'this' pointer it works, but when I typecast 'this' to the SAME class' pointer type (i.e., B only) in class B's constructor, then it throws an exception at run time and this is where I am confused. So same place, call using 'this' works whereas call using B* fails. I apologize if you already answered this. But I am not yet able to figure it out. It throws exception in g++4.4 and Visual Studio both. – Selfpollination

@siddhusingh: It's undefined behaviour. Anything can happen. You provide a definition for the pure virtual, so in some cases you happen to see that one being called, and in other cases the compiler decides to make an optimization that it is permitted to do and crashes your program. Such is the nature of undefined behaviour -- any behaviour is 'correct'! – Concent

@siddhusingh: I added some explanation of what's probably happening! – Concent

Answer 2

This is the incorrect procedure for what you are probably trying to do.

You need a 2-phase construction and for that you should use a factory object that creates the class then calls the virtual method on it.

One may actually call a non-pure virtual function from a constructor or destructor, but then you must know that what is going to get called is the method from the class itself and not anything polymorphic.

Calling a pure virtual function from a constructor is undefined behaviour. This will be the case whenever your class is being constructed, whether it calls it directly from the constructor (which a compiler might be able to trap and warn about) or from a method your constructor calls (which would be potentially beyond the scope of the compiler or linker to detect).

Fifi