From the storage space point of view
A 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, assuming that the constructor is virtual. It needs vtable
to be called through. But the object is not 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 the corresponding call. The constructor itself is the instance to initialize. It doesn't really make sense 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 by itself when the object is created, and cannot be called by a pointer or reference to the parent class . (no need to exist). Therefore, it is also stipulated that the constructor cannot be a virtual function.
Constructors do not need to be virtual functions. Nor does it agree that it is a virtual function
Because we always have to understand the type of the specified object when creating an object. Although we may be able to access it through a pointer or reference to a base class, the destructor is not necessarily, we often destroy the object by a pointer to the base class. Assuming that 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
vbtl
Built 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, run only once for the lifetime of the object, not the object's dynamic behavior, and it is not necessary to become a virtual function .
virtual function Table Implementation angle
When a constructor is invoked. One of the first things it does is initialize it VPTR
.
So. It only knows 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, just want it to be the last constructor call, then within the lifetime of this object. VPTR
will remain initialized to point to this VTABLE
, but assuming that another later derived constructor is called, the constructor will then VPTR
point to it VTABLE
, and so on until the last constructor ends. 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 VPTR
to point to its own VTABLE
. Assume that a function call uses a virtual mechanism. It will only be generated through its own VTABLE
invocation, not the last VTABLE
(all constructors are called after the last VTABLE
).
Why a constructor cannot be a virtual function