[C ++] hidden problems caused by destructor and virtual functions-Objective C ++

In the factory mode, we often point a base class pointer to a subclass object to realize polymorphism. However, when you call Delete to describe this base class pointer, there is a hidden crisis:When a subclass object is deleted by a base class pointer and the base class carries a non-virtual destructor, the result is unpredictable-in actual execution, the child components of the object are not destroyed! It is easy to eliminate this problem:Returns a virtual destructor to the base class.. If a class does not contain virtual functions, it usually indicates that it is not intended to be used as a base class. Do not add virtual functions to such a class!Otherwise, the running overhead will be increased, and the addition of VBR will increase the object size, which will also cause confusion in the details of the object and cannot communicate with functions in other languages. The experience is as follows:1Virtual destructor are declared only when the class contains virtual functions.2The class without the virtua; the class of the destructor pointer is better not to be a base class.3Do not try to inherit from a standard container or any other class with non-virtual destructor. What if you want to have an abstract class without pure virtual functions? The answer is:Declare a pure virtual destructor for this class, and then provide a definition for this destructor.(Because it must be called when the Destructor subclass is created ). This rule only applies to classes designed for polymorphism. Advice: A base class with polymorphism should declare a virtual destructor. If a class has any virtual function, it should have a virtual Destructor. Virtual destructor should not be declared if the class is not designed to be used as a base class or to have polymorphism. When a class destructor throws an exception, the program may end prematurely or have ambiguous behaviors (resource leakage). C ++ does not like destructor to throw an exception! Conventional method:1If exceptions are caught in the destructor, the program is forcibly released to avoid propagation of ambiguous behaviors.2Ignore exceptions (catch exceptions and do nothing ). Better method:Write a common function to perform the destructor, and then call this function in the destructor.Allow the user to call close (it is implicitly called in the Destructor even if the user does not explicitly call it). This gives the user a chance to handle possible exceptions. Advice: Do not throw an exception to the destructor. If a function called by the Destructor may throw an exception, the Destructor should catch any exception and ignore or force the program to end. If you need to respond to exceptions excluded during the running of an operation function, you should provide a common function (instead of in the destructor) to perform the operation. If you want to call the virtual function in the constructor, you will not get the expected result. During the construction of the base class, the virtual function will never be dropped to the subclass. The object is like a base class.In fact, the virtual function is not a virtual function during the construction of the base class. This is because when the base class is constructed, the sub-class components are not yet constructed. How can a function be available for calling! The same principle applies to destructor. If the virtual function is called in the destructor of the base class, the sub-class components have been destructed during execution. The only way to avoid this problem is:Make sure that your constructor and destructor do not call the virtual function throughout the execution process. If you want to implement the polymorphism construction of some members, some sub-classes should pass some information like some functions of the parent class, and then these functions will perform the polymorphism construction, instead of getting some virtual functions in the constructor. "Because you cannot use the virtual function to call down from the base class, during the construction, you can make the subclass pass the necessary constructor information to the base class constructor ." Advice: Do not call virtual functions during construction and analysis, because such calls never fall into the subclass.

In the factory mode, we often point a base class pointer to a subclass object to realize polymorphism. However, when you call Delete to describe this base class pointer, there is a hidden crisis:When a subclass object is deleted by a base class pointer and the base class carries a non-virtual destructor, the result is unpredictable-in actual execution, the child components of the object are not destroyed! It is easy to eliminate this problem:Returns a virtual destructor to the base class.. If a class does not contain virtual functions, it usually indicates that it is not intended to be used as a base class. Do not add virtual functions to such a class!Otherwise, the running overhead will be increased, and the addition of VBR will increase the object size, which will also cause confusion in the details of the object and cannot communicate with functions in other languages. The experience is as follows:1Virtual destructor are declared only when the class contains virtual functions.2The class without the virtua; the class of the destructor pointer is better not to be a base class.3Do not try to inherit from a standard container or any other class with non-virtual destructor. What if you want to have an abstract class without pure virtual functions? The answer is:Declare a pure virtual destructor for this class, and then provide a definition for this destructor.(Because it must be called when the Destructor subclass is created ). This rule only applies to classes designed for polymorphism. Advice: A base class with polymorphism should declare a virtual destructor. If a class has any virtual function, it should have a virtual Destructor. Virtual destructor should not be declared if the class is not designed to be used as a base class or to have polymorphism. When a class destructor throws an exception, the program may end prematurely or have ambiguous behaviors (resource leakage). C ++ does not like destructor to throw an exception! Conventional method:1If exceptions are caught in the destructor, the program is forcibly released to avoid propagation of ambiguous behaviors.2Ignore exceptions (catch exceptions and do nothing ). Better method:Write a common function to perform the destructor, and then call this function in the destructor.Allow the user to call close (it is implicitly called in the Destructor even if the user does not explicitly call it). This gives the user a chance to handle possible exceptions. Advice: Do not throw an exception to the destructor. If a function called by the Destructor may throw an exception, the Destructor should catch any exception and ignore or force the program to end. If you need to respond to exceptions excluded during the running of an operation function, you should provide a common function (instead of in the destructor) to perform the operation. If you want to call the virtual function in the constructor, you will not get the expected result. During the construction of the base class, the virtual function will never be dropped to the subclass. The object is like a base class.In fact, the virtual function is not a virtual function during the construction of the base class. This is because when the base class is constructed, the sub-class components are not yet constructed. How can a function be available for calling! The same principle applies to destructor. If the virtual function is called in the destructor of the base class, the sub-class components have been destructed during execution. The only way to avoid this problem is:Make sure that your constructor and destructor do not call the virtual function throughout the execution process. If you want to implement the polymorphism construction of some members, some sub-classes should pass some information like some functions of the parent class, and then these functions will perform the polymorphism construction, instead of getting some virtual functions in the constructor. "Because you cannot use the virtual function to call down from the base class, during the construction, you can make the subclass pass the necessary constructor information to the base class constructor ." Advice: Do not call virtual functions during construction and analysis, because such calls never fall into the subclass.

In the factory mode, we often point a base class pointer to a subclass object to realize polymorphism. However, when you call Delete to describe this base class pointer, there is a hidden crisis: When a subclass object is deleted by a base class pointer and the base class carries a non-virtual destructor, the result is unpredictable-in actual execution, the child components of the object are not destroyed!
It is easy to eliminate this problem: Returns a virtual destructor to the base class..

If a class does not contain virtual functions, it usually indicates that it is not intended to be used as a base class. Do not add virtual functions to such a class!Otherwise, the running overhead will be increased, and the addition of VBR will increase the object size, which will also cause confusion in the details of the object and cannot communicate with functions in other languages.
The experience is as follows:1Virtual destructor are declared only when the class contains virtual functions.2The class without the virtua; the class of the destructor pointer is better not to be a base class.3Do not try to inherit from a standard container or any other class with non-virtual destructor.

What if you want to have an abstract class without pure virtual functions?
The answer is:Declare a pure virtual destructor for this class, and then provide a definition for this destructor.(Because it must be called when the Destructor subclass is created ). This rule only applies to classes designed for polymorphism.

Advice:

A base class with polymorphism should declare a virtual destructor. If a class has any virtual function, it should have a virtual
Destructor.

Virtual destructor should not be declared if the class is not designed to be used as a base class or to have polymorphism.

When a class destructor throws an exception, the program may end prematurely or have ambiguous behaviors (resource leakage). C ++ does not like destructor to throw an exception!
Conventional method:1If exceptions are caught in the destructor, the program is forcibly released to avoid propagation of ambiguous behaviors.2Ignore exceptions (catch exceptions and do nothing ).
Better method:Write a common function to perform the destructor, and then call this function in the destructor.Allow the user to call close (it is implicitly called in the Destructor even if the user does not explicitly call it). This gives the user a chance to handle possible exceptions.

Advice:

Do not throw an exception to the destructor. If a function called by the Destructor may throw an exception, the Destructor should catch any exception and ignore or force the program to end.

If you need to respond to exceptions excluded during the running of an operation function, you should provide a common function (instead of in the destructor) to perform the operation.

If you want to call the virtual function in the constructor, you will not get the expected result. During the construction of the base class, the virtual function will never be dropped to the subclass. The object is like a base class.In fact, the virtual function is not a virtual function during the construction of the base class. This is because when the base class is constructed, the sub-class components are not yet constructed. How can a function be available for calling!
The same principle applies to destructor. If the virtual function is called in the destructor of the base class, the sub-class components have been destructed during execution.

The only way to avoid this problem is:Make sure that your constructor and destructor do not call the virtual function throughout the execution process.

If you want to implement the polymorphism construction of some members, some sub-classes should pass some information like some functions of the parent class, and then these functions will perform the polymorphism construction, instead of getting some virtual functions in the constructor. "Because you cannot use the virtual function to call down from the base class, during the construction, you can make the subclass pass the necessary constructor information to the base class constructor ."

Advice:

Do not call virtual functions during construction and analysis, because such calls never fall into the subclass.