9

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 ?
}
curiousguy
  • 8,038
  • 2
  • 40
  • 58
iammilind
  • 68,093
  • 33
  • 169
  • 336

3 Answers3

19

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.

Ben Voigt
  • 277,958
  • 43
  • 419
  • 720
  • Does this mean that the `vptr` will be modified every time when the base subobjects constructed, if there are many levels of derivation? – fengqi Jul 27 '17 at 07:50
  • @fengqi 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), ... – curiousguy Jul 09 '18 at 02:30
  • ... 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. – curiousguy Jul 09 '18 at 02:34
  • ... (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.) – curiousguy Jul 09 '18 at 02:37
3

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..)

tp1
  • 1,197
  • 10
  • 17
0

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 "
  • 1
    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. – Ben Voigt Aug 11 '15 at 19:30
  • 1
    "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. – SJHowe Jul 24 '19 at 11:50