When to define a virtual destructor

[jeff_rowa]

Hello people,
I know that in a base class you should define the destructor as virtual but is there any cases that you define a destructor as virtual. In the case when you implement assignment operator and copy constructor you need to implement the destructor as well but does it need to be virtual too or not?

many thanks

[Savage]

Hello people,
I know that in a base class you should define the destructor as virtual but is there any cases that you define a destructor as virtual. In the case when you implement assignment operator and copy constructor you need to implement the destructor as well but does it need to be virtual too or not?

many thanks

I really don't understand what are you trying to say.

Could you please rephrase somehow?

Savage

[jeff_rowa]

I really don't understand what are you trying to say.

Could you please rephrase somehow?

Savage

well what I'm saying basically is when do you define a destructor as virtual besides in inheritance and for the base class.

[RRick]

Whew! Destructors and copy methods! While this is an innocent question, you have really opened up a big C++ can of worms.

First of all, the destructor, copy constructor and operator= are known as the "Big 3" methods and many times are grouped together. Some sources say that if you implement one of them, you should implement all of them. In this case, disabling a method by making it private counts as an implementation.

Notice that the above discussion makes no mention of the destructor being virtual. You must make the destructor virtual, if you have any plans to derive from this class. If you don't, you can introduce a bug due to "splicing". Does this mean the base class also has to define the copy methods, too? Only if the desctructor is releasing resources. I believe this is one of the few exceptions to the Big 3 rule.

The operator= can be made virtual (I think) but I haven't seen an example for doing this. Most cases for using operator= is between the same class. I believe operator= can be used to copy between base and derived classes (but I wouldn't bet the house on it). To me, this sounds like a diaster.

One last point on copying. There is a real need to make copies of derived objects from base class pointers. In this case, a technique called cloning is used where a virtual clone method is created.

[Savage]

well what I'm saying basically is when do you define a destructor as virtual besides in inheritance and for the base class.

It's good to have always a virtual destructor,you might need to derive from that class in a future to avoid reinventing the wheel,so whenever you can make it virtual unless your primary goal is speed.

Savage

[weaknessforcats]

All of the above answers are incorrect.

A virtual destructor has nothing to do with the "Big 3" or the assignment operator.

You have to understand that only the compiler can create and destroy objects. As a courtesy, on creation the compiler will call a constructor so you can intialize any class members that haven't alreay been initialized. On destruction, a courtesy call to your destructor allows you to release any resources you may have allocated or to do any last minute work as the result of the object being destroyed.

Where a hierarchy is involved with a base class having virtual functions, the intent is to use base class pointers and references with derived objects. So, when you delete a base class pointer or reference, the base class destructor is called. And that's all.

If you you want your derived class destrutctor called, then the base class destructor must be virtual. In this case, the derived class destructor is called followed by a call to the base class destrcutor.

The rule is: If your base class has virtual functions, then it must have a virtual destrcutor. Otherwise, it's a design error.

A base class with no virtual functions and a virtual destrcutor is likewise a design error.

[RRick]

Actually, all of the above answers are correct; at least within their posts.

Savage took a safe path and suggested that all objects should have virtual destructors. This would stop the base class design flaw W4cats mentioned.

I personally don't care for this approach, but then I usually have access to the base class code, and can fix the above mentioned design flaw by modifying the destructor directly. If I can't access the original code, then I can wrap my own class around the offending object and hide its bad design with protected inheritence.

It might be my old C style coding habits, but I don't like making a class virtual ( and creating a virtual lookup table) unless it is really needed.

[weaknessforcats]

It might be my old C style coding habits, but I don't like making a class virtual ( and creating a virtual lookup table) unless it is really needed.

Actually, this is exactly what you want. The base class object is really part of the derived object. When you call a base class private virtual method using a base class pointer, you want the call to be to the derived class override.

That means in object-oriented programming you base class will always need a vtbl.

Check out separating the interface from the implementation by reading up on the desing pattern Template Method.

I say again, a class with virtual functions and no virtual destructor is a design error.

[Savage]

Actually, this is exactly what you want. The base class object is really part of the derived object. When you call a base class private virtual method using a base class pointer, you want the call to be to the derived class override.

That means in object-oriented programming you base class will always need a vtbl.

Check out separating the interface from the implementation by reading up on the desing pattern Template Method.

I say again, a class with virtual functions and no virtual destructor is a design error.

Then why you said that my statement is incorrect?

I did said that it's good to always have a vdestructor,exc ept when your goal is speed.

Savage

[weaknessforcats]

Then why you said that my statement is incorrect?

I did said that it's good to always have a vdestructor,exc ept when your goal is speed.

Sorry. I was referring to RRick's post #7.

Your statement of having virtual destructors for no reason on the off chance you will derive from the class in the future does not hold water. The reason is that this is a concrete class. That is, a class from which objects can be created.

When you derive from a concrete class, you cannot override base class methods since they aren't virtual. Your derived methods will just hide the base methods and remove that functionality from your derived class. That forces code like:

void Derived::AMethod(int arg)
{
       //Derived code goes here???
       Base::AMethod();    //recover base class functionality
       //Or does it go here???
}
 

Unfortuntately, now you can't tell whether the Base method call is a pre-condtion or a post-condition in the derived class and therefore have introduced ambiguity.

So the rule is: Never derive from a concrete class.

When you do derive, the base class will have virtual methods and that requires the virtual destructor.