C ++ Summary of precautions related to "class" (9): Determine whether the base class has a virtual destructor

Imagine a military applicationProgramThere is a class that represents the enemy's target:

Class enemytarget

{
Public:
Enemytarget () {++ numtargets ;}
Enemytarget (const enemytarget &) {++ numtargets ;}
~ Enemytarget () {-- numtargets ;}

Static size_t numberoftargets ()
{Return numtargets ;}

Virtual bool destroy (); // After the enemytarget object is destroyed
// Return success

PRIVATE:
Static size_t numtargets; // object counter
};

// Static members of a class should be defined outside the class;
// The default initialization value is 0.

Size_t enemytarget: numtargets;

The enemy's tank is a special enemy target, so it is natural to think of abstracting it into a class derived from enemytarget in the form of public inheritance. Because we should not only care about the total number of enemy targets, but also the total number of enemy tanks, so like the basic class, we also use the same technique mentioned above in the derived class:

Class enemytank: Public enemytarget {
Public:
Enemytank () {++ numtanks ;}

Enemytank (const enemytank & RHs)
: Enemytarget (RHs)
{++ Numtanks ;}

~ Enemytank () {-- numtanks ;}

Static size_t numberoftanks ()
{Return numtanks ;}

Virtual bool destroy ();

PRIVATE:
Static size_t numtanks; // tank object counter
};

Finally, assume that an enemytank object is dynamically created using new somewhere else in the program, and then deleted using delete:

Enemytarget * targetptr = new enemytank;

...

Delete targetptr

This will cause a serious problem, because the C ++ language standards are very clear about this issue: when the base class pointer is used to delete the object of the derived class, when the base class does not have a virtual destructor, the result is uncertain. In practice, the destructor of a derived class will never be called. In this example, this means that when targetptr is deleted, the number of enemytank will not change, and the number of enemy tanks is wrong.

If a class does not contain a virtual function, it generally means that it will not be used as a base class. When a class is not used as a base class, it is generally a bad idea to make the Destructor virtual. Because it adds a virtual function table to the class, doubling the object size and possibly reducing its portability.

So the basic one is: declaring a virtual destructor for no reason is the same as never declaring it. In fact, many people have concluded that virtual destructor are declared only when the class contains at least one virtual function.

Abstract classes are intended to be used as base classes. The base classes must have a virtual destructor. Pure virtual functions generate abstract classes, so the method is simple: declare a pure virtual destructor in the class to be an abstract class.

Here is an example:

Class awov {// awov = "abstract w/o
// Schemals"
Public:
Virtual ~ Awov () = 0; // declare a pure virtual destructor
};

This class has a pure virtual function, so it is abstract, and it has a virtual destructor, so it will not produce the problem of destructor. But here is another thing: the definition of pure virtual destructor must be provided:

Awov ::~ Awov () {}// definition of pure virtual destructor

This definition is required, because the virtual destructor work in the following way: the destructor of the bottom-layer derived class is called first, and then the destructor of each base class is called. That is to say, even an abstract class, the compiler must generate a pair ~ Make sure to provide the function body for the awov call. If you do not do this, the linker will detect it and you have to add it back.

Note: If you declare a virtual destructor as inline, the overhead generated when you call them will be avoided, but the compiler will inevitably generate a copy of the function somewhere.