Precautions for implementing C ++ virtual functions

In C ++, the role of the C ++ Virtual Function is mainly to implement the polymorphism mechanism. The Virtual Function is implemented through a Virtual Function Table Virtual Table, v-Table for your reference!

If a class does not contain virtual functions, this often indicates that it is not intended to be used as a base class. When a class is not intended as a base class, it is usually a bad idea to declare the Destructor as virtual. Consider a class that represents vertices in a two-dimensional space:

 
 

  
  
class Point { // a 2D point  
  
  
　public:  
  
  
Point(int xCoord, int yCoord);  
  
  
~Point();  
  
  
　private:  
  
  
int x, y;  
  
  
};  
 
 

If an int occupies 32 bits, a Point object is suitable for 64-bit registers. In addition, such a Point object can be passed as a 64-bit volume to functions written in other languages, such as C or FORTRAN. If the Point destructor are virtual, the situation is completely different.

The implementation of the C ++ virtual function requires that the object carry additional information to determine which virtual function the object should call at runtime. In typical cases, this information has a pointer form called vptrvirtual table pointer, a virtual function table pointer.

Vptr points to a function pointer array called vtblvirtual table (virtual function table). Every class containing C ++ virtual functions is associated with vtbl. When an object calls a virtual function, the actually called function is determined through the following steps: Find the vtbl to which the object's vptr points, and then find the appropriate function pointer in vtbl.

The details of how a virtual function is implemented are not important. It is important that if the Point class contains a virtual function, the object size of this type will increase. In a 32-bit architecture, they will grow from 64-bit to two int) to 96-bit two int plus vptr );

In a 64-bit architecture, they may grow from 64-bit to 128-bit, because in this architecture, the pointer size is 64-bit. Adding a vptr to a Point will increase its size by 50-100%! The Point object is no longer suitable for 64-bit registers. In addition, the Point object is in C ++ and other languages such as C.

It does not seem to have the same structure, because other languages lack vptr pairs. As a result, Points is no longer allowed to pass in functions written in other languages or from them unless you make a clear correspondence for the vptr, which is its own implementation details and thus no portability.

The benchmark here is that it is wrong to declare all destructor as virtual without adding them as virtual. In fact, many people have summarized this rule: When and only when the class contains at least one virtual function, a virtual destructor is declared.

However, when there is no C ++ virtual function at all, the non-virtual destructor problem may occur. For example, the standard string type does not contain C ++ virtual functions, but the misleading programmer sometimes treats it as a base class:

 
 

  
  
SpecialString *pss = new SpecialString("Impending Doom");  
  
  
 
  
  
std::string *ps;  
  
  
...  
  
  
ps = pss; // SpecialString* => std::string*  
  
  
...  
  
  
delete ps; // undefined! In practice,  
  
  
// *ps’s SpecialString resources  
  
  
// will be leaked, because the  
  
  
// SpecialString destructor won’t  
  
  
// be called.  
 
 

At a glance, this may be harmless. However, if you convert a pointer to SpecialString to a pointer to string somewhere in the program for some reason, then you apply delete to this string pointer, And you are immediately sent to the territory of undefined behavior.

1. Differences between standard input implementation methods in C and C ++
2. How does the C ++ compiler allocate storage space for Const constants?
3. Basic Conception and method of C ++ Class Library Design
4. Several Methods for converting C ++ Language
5. How to better compile C ++ code