Why a constructor cannot be a virtual function

1 when constructing an object, you must know the actual type of the object, and the virtual function behavior is to determine the actual type during run time. While constructing an object, the object has not yet been constructed successfully. The compiler cannot know the actual type of the object, whether it is the class itself, or a derived class of that class, or a deeper derived class. Unable to determine ...

2 execution of virtual functions relies on virtual function tables . The virtual function table is initialized in the constructor, that is, initializing the vptr to point to the correct virtual function table. during the construction of the object, the virtual function table is not initialized and will not be able to proceed.

More:

1. From the storage space angle, the virtual function corresponds to a pointer to the vtable virtual function table, which we all know, but this pointer to vtable is actually stored in the object's memory space. The problem comes out, if the constructor is virtual, it needs to be called through vtable, 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. 2. From the perspective of Use, virtual function is mainly used in the case of incomplete information, can make the overloaded function to get the 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, so the constructor cannot be a virtual function. 3. 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 a pointer or reference to the base class in the lab, but the destructor is not necessarily, we often destroy the object through 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. 4. From the implementation perspective, VBTL is established after the constructor call, so the constructor cannot be a virtual function from the actual meaning, when the constructor is called to determine the real type of the object (because the subclass will call the constructor of the parent class), and the function of the constructor is to provide initialization, only once in the object lifetime, is not a dynamic behavior of an object, nor is it necessary to become a virtual function. 5. When a constructor is called, one of the first things it does is initialize its 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 the vptr that it uses must be for this class of vtable. And, as long as it is the last constructor call, the vptr will remain initialized to point to this VTABLE during the lifetime of the object, but if there is a later derived constructor called, the constructor sets Vptr to its VTABLE, And so on. Until the end of the constructor function. The state of the vptr 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 points to its own vtable. If a function call uses a virtual mechanism, it will only produce a V through its ownThe call to the table, not the last vtable (all constructors are called after the last vtable). Reference: http://blog.csdn.net/wangfutao01/article/details/6472291

Why a constructor cannot be a virtual function