Why cannot a constructor be a virtual function?

1. From the perspective of storage space, virtual functions correspond to a pointer to the vtable virtual function table. We all know that this pointer to vtable is actually stored in the object's memory space. The problem arises. If the constructor is virtual, it needs to be called through vtable, but the object has not been instantiated, that is, the memory space is not yet available. How can we find vtable? Therefore, the constructor cannot be a virtual function.

2. From the perspective of usage, virtual functions are mainly used to call a function that can be reloaded if the information is incomplete. The constructor itself is to initialize the instance, so it does not actually make sense to use the virtual function. Therefore, the constructor does not need to be a virtual function. The role of a virtual function is to call the member function of the subclass when calling it through the pointer or reference of the parent class. The constructor is automatically called when an object is created. It cannot be called through the pointer or reference of the parent class. Therefore, the constructor cannot be a virtual function.

3. the constructor does not need to be a virtual function or a virtual function, because we always need to specify the object type when creating an object, although we may access it through the base class pointer or reference in the lab, the structure is not necessarily, we often destroy objects through the base class pointer. At this time, if the Destructor is not a virtual function, it cannot correctly identify the object type and thus cannot call the Destructor correctly.

4. from the implementation point of view, vbtl is established after the constructor is called, so the constructor cannot become a virtual function, the real type of the object cannot be determined when the constructor is called (because the child class calls the constructor of the parent class). Moreover, the constructor provides initialization and only executes the object once during its lifetime, it 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 its first tasks is to initialize its vptr. Therefore, it can only know that it is a "current" class, and ignore whether there is a successor behind this object. When the compiler generates code for this constructor, it generates code for the constructor of this class-neither the base class nor, it is not a derived class for it (because the class does not know who inherits it ). Therefore, the vptr used must be a vtable for this class. In addition, as long as it is the final constructor call, during the lifetime of this object, vptr will be initialized to point to this vtable, however, if another later-derived constructor is called, this constructor will set vptr to point to its
Vtable, and so on until the end of the final constructor. The status of the vptr is determined by the final called constructor. This is another reason why constructor calls are ordered from the base class to a more derived class. However, when this series of constructor calls occur, each constructor has set vptr to point to its own vtable. If a function call uses a virtual mechanism, it will only generate a call through its own vtable, rather than the final vtable (the final vtable will be generated after all constructors are called ).

From: http://www.cnblogs.com/lixiaohui-ambition/archive/2012/08/28/2660708.html