When does the vptr (pointing to vtable) get initialized for a polymorphic class?

Question

This is not about "When VTABLE is created?". Rather, when the VPTR should be initialized? Is it at the beginning/end of the constructor or before/after the constructor?

A::A () : i(0), j(0)  -->> here ?
{
  -->> here ?
  //...
  -->> here ?
}

Wilful

Answer 1

The machinery for virtual calls (usually a v-table, but doesn't need to be) is set up during the ctor-initializer, after construction of base subobjects and before construction of members. Section [class.base.init] decrees:

Member functions (including virtual member functions, 10.3) can be called for an object under construction. Similarly, an object under construction can be the operand of the typeid operator (5.2.8) or of a dynamic_cast (5.2.7). However, if these operations are performed in a ctor-initializer (or in a function called directly or indirectly from a ctor-initializer) before all the mem-initializers for base classes have completed, the result of the operation is undefined.

Actually, during construction of the base subobjects, the virtual function machinery exists, but it is set up for the base class. Section [class.cdtor] says:

Member functions, including virtual functions (10.3), can be called during construction or destruction (12.6.2). When a virtual function is called directly or indirectly from a constructor or from a destructor, including during the construction or destruction of the class’s non-static data members, and the object to which the call applies is the object (call it x) under construction or destruction, the function called is the final overrider in the constructor’s or destructor’s class and not one overriding it in a more-derived class. If the virtual function call uses an explicit class member access (5.2.5) and the object expression refers to the complete object of x or one of that object’s base class subobjects but not x or one of its base class subobjects, the behavior is undefined.

Setiform

Does this mean that the vptr will be modified every time when the base subobjects constructed, if there are many levels of derivation? – Decode

@Decode Yes in the general case the various vptr (at least one for each direct polymorphic base) is modified. But in the specific case with no call from a ctor to a separately compiled function that has access to this, the complete inlining on the virtual-ness of x this of base class ctors, where "complete inlining on Info" means inlining on all directly and indirectly called functions that could possibly have access to Info, and "the virtual-ness of x" is all features or behaviors that depend on the dynamic type of x (notably virtual function calls), ... – Rooted

... so "the complete inlining on the virtual-ness of x this of base class ctors" means the recursive inlining of all functions called from base class ctors that might call a virtual function on this (or use typeid(*this) or dynamic_cast), brings possible optimization on the changes of the vptr. This is esp. the case where the base class ctor has an empty body and no member object with a non inline construction, a particular case where the it's fully recursively inlinable: such base class constructor doesn't ever see the vptr value. – Rooted

... (Note that the transformation isn't possible if any data member M of that base subobject B has a separately compiled construction and that base subobject has another base class BB with separately compiled construction, as the this pointer provided to the constructor of M by the base constructor of BB might use a dynamic operation during the initialization of the member object.) – Rooted

Answer 2

it's initialized between the constructors of base and derived classes:

class Base { Base() { } virtual void f(); };
class Derived { Derived(); virtual void f(); };

It happens when raw memory is converted to Base object. It happens when Base object is converted to Derived object during construction of an object. Same obviously happens in reverse when destroying object. I.e. every time when type changes, the vtable pointer is changed. (I'm sure someone comments that vtables don't need to exists according to the std..)

Roderickroderigo

Answer 3

This msdn article explains it in great detali

There it says :

"And the final answer is... as you'd expect. It happens in the constructor."

so..
A::A () : i(0), j(0)
{
-->> here !
//...
//
}

But be careful, let's say you have the class A, and a class A1 derived from A.

• If you create a new A object, the vptr will be set right at the beginning of the constructor of the A class
• But if you were to create a new object A1:

"Here's the entire sequence of events when you construct an instance of class A1:

1. A1::A1 calls A::A
2. A::A sets vtable to A's vtable
3. A::A executes and returns
4. A1::A1 sets vtable to A1's vtable
5. A1::A1 executes and returns "

Karaganda

The first Standard quote I gave in my answer shows that your explanation is not quite right. When you add a late answer, it's good to read and understand the existing answers, just in case. – Setiform

"here !" is wrong. I don't find "it happens in the constructor" helpful. Where, SPECIFICALLY in the constructor? Before member initialisation? After member initialisation? At the start of body? At the end of the body? The answer is, after the right curly brace. Because for a Derived constructor, if you call a virtual function, just before the right curly brace, you're still getting Base class services, not Derived. Any virtual table adjustment must occur after the body of the constructor has run. – Guaranty