1, from the storage space angle
The virtual function corresponds to a vtable, which we all know, but this vtable is actually stored in the object's memory space. The problem is that 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 available, and the vtable cannot be found, so the constructor cannot be a virtual function.
2, 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, 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 explicitly specify the type of object when creating an object, although we may access it through pointers or references to the base class in the lab. But destruction is not necessarily, we tend to destroy objects through the base class pointers. 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 of the view, VBTL after the constructor call is established, so the constructor can not 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, only once for the lifetime of the object, not the dynamic behavior of the 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 v P T R. 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 uses the V P T R must be for this class of V TA B L E. And, as long as it is the last constructor call, the V P t R will remain initialized to point to this v TA b l e during the lifetime of this object, but if a later derived constructor is called, the constructor will then set V P t R to point to its V TA b l E, etc. until the most The end of the constructor function. The state of V P T R is determined by the last called constructor. 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 set v P T R to point to its own v TA B L E. If a function call uses a virtual mechanism, it will only produce a call through its own v TA b l E, instead of the last V Ta b l E (all constructors are called after the last V Ta b l e).
Turn from:
Http://blog.sina.com.cn/s/blog_620882f401016ri2.html
Reprint: Why a constructor cannot be a virtual function