Why a constructor cannot be a virtual function

From the storage space point of view

The virtual function corresponds to a vtable pointer to a virtual function table, which we all know, but this vtable pointer is actually stored in the object's memory space. The problem comes out, if the constructor is virtual, it needs vtable to be called through, but the object has not been instantiated, that is, the memory space is not yet, how to find vtable it? So the constructor cannot be a virtual function.

From the angle of use

Virtual function is mainly used in the case of incomplete information, can make the overloaded function get corresponding call. The constructor itself is to initialize the instance, and it has no practical meaning to use virtual functions. So the constructor is not necessarily a virtual function. the function of a virtual function is to call it through a pointer or reference to the parent class to become the member function that invokes the subclass. The constructor is called automatically when the object is created and cannot be called by a pointer or reference to the parent class (no need exists), so the constructor cannot be a virtual function.

The constructor does not need to be a virtual function, nor is it allowed to be a virtual function

Because we always have to explicitly specify the type of object when creating an object, although we may access it through pointers or references to the base class but not necessarily, we often destroy objects by pointers to the base class. At this point, if the destructor is not a virtual function, the object type cannot be correctly identified and the destructor cannot be called correctly.

From the perspective of implementation

vbtlBuilt after a constructor call, so the constructor cannot be a virtual function. From a practical point of view, it is not possible to determine the real type of an object when calling the constructor (because the subclass will call the constructor of the parent class), and the function of the constructor is to provide initialization, which is performed only once in the lifetime of the object, not the object's dynamic behavior, nor is it necessary to become a virtual function .

virtual function Table Implementation angle

When a constructor is called, one of the first things it does is initialize it VPTR . Therefore, it can only know that it is the "current" class, and completely ignores whether there are successors behind the object. When the compiler generates code for this constructor, it generates code for the constructor of the class-neither for the base class nor for its derived class (because the class does not know who inherits it). So it VPTR must be used for this class VTABLE . And, as long as it is the last constructor call, it will remain initialized to point to this during the lifetime of the object, VPTR VTABLE But if a later derived constructor is called, the constructor will then VPTR point to it VTABLE , Wait until the end of the constructor function. VPTR State is determined by the constructor that was last called . This is another reason why constructor calls are from the base class to the order of the more derived classes. However, when this series of constructor calls is occurring, each constructor has been set to VPTR point to its own VTABLE . If a function call uses a virtual mechanism, it will only generate calls through its own VTABLE , not the last VTABLE (all constructors are called after the last VTABLE ).

Why a constructor cannot be a virtual function