is it possible to override destructor ? what care we have to take when we use it ?

[SimonSchroeder]

Well, you can't override a constructor or destructor in the same way you override a regular member function. For member functions overriding means to completely replace the function. If you want to include the behavior of the member function in the super class you have to be explicit. For constructors and destructors a call to the super class happens implicitly. So, in this sense you cannot override constructors or destructors. It depends on your definition.

Another way of looking at this is that with overridden member functions – and also destructors – you can use a pointer to the base class to call them. In this sense constructors cannot be overridden. If you call the constructor of the base class, how should the compiler know to call a constructor of a derived class? Let alone how should the compiler know of which derived class to call the constructor if there are multiple derived classes. From this point of view constructors can (fortunately!!!) not be overridden (in C++).

@Qt-embedded-developer said in is it possible to override destructor ? what care we have to take when we use it ?:

what we have to take care when we override destructor ?

You have to be careful when you don't override the destructor. If you actually override the destructor everything will work as it should. If you forget, however, to override the destructor weird things can happen if you really should've overridden it.

[JonB]

@SimonSchroeder said in is it possible to override destructor ? what care we have to take when we use it ?:

It depends on your definition.

Yes, this is my feeling, as a I wrote earlier. It gets tricky with definitions. "Overriding" constructor or destructor is certainly a bit different from any other method.

Having read about it and thought about it now, I think/suspect that the actual answer is: you can override destructor but not constructor.

I base this on two things:

• You override where you can write the keyword override. Simplez. That applies for destructor but not for constructor.

• You have a vtable entry to override. During constructor there simply is no vtable entry set up yet.

I maintain that conceptually you should just think of a derived class's constructors & destructor in terms of overriding, in that you can provide your own code. And although you do not call the base destructor explicitly it, and the base constructor, run implicitly, so you at least have to think about that.

[kkoehne]

Another way of looking at this is that with overridden member functions – and also destructors – you can use a pointer to the base class to call them. In this sense constructors cannot be overridden.

I think this is spot on. If you check out the actual C++ standard, it uses the word 'override' only in the context of virtual methods. And destructors can be virtual, while constructors can't.

Check out e.g.§ 11.7.2, "Virtual Methods" of the latest the C++ standard (emphasis all mine):

A non-static member function is a virtual function if it is first declared with the keyword virtual or if it *overrides* a virtual member function declared in a base class.

and then later on

Even though destructors are not inherited, a destructor in a derived class *overrides* a base class destructor declared virtual.

[J.Hilk]

@JoeCFD said in is it possible to override destructor ? what care we have to take when we use it ?:

@Qt-embedded-developer add virtual to all of your destructors and make it a habit.

oh no don't do that,

in fact I would go so far and say: Do not add a destructor at all, if you do not need it! It can and will lead to unnecessary overhead, errors, and inefficient code.

Same as with copy/move constructors/assignment operators. If you don't do anything really fancy in them, let it default and therefore let the compiler handle it. I will be much better :p

[JoeCFD]

@Chris-Kawa Got it. Qt uses virtual destructors all over the places across the framework. So it may be a laggy or battery eating apps. You are a Qt moderator. Are we still good?

[JoeCFD]

@J-Hilk I agree with you that do not add a destructor if it is not needed. But when it is needed, I would prefer to make it virtual.

[Chris Kawa]

@JoeCFD said:

Qt uses virtual destructors all over the places across the framework

It was one of the pillars of the original Qt project that it would put flexibility, cross-platform and ease of use above performance. It is designed around a complex inheritance structure, so yeah, that cost is part of it. It does try to mitigate some of it with tricks like qobject_cast, which somewhat alleviates the pain of dynamic_casts necessary in such designs, but in the end performance is secondary in Qt's design, no question about it.
Keep in mind though, that UI frameworks, not just Qt, are kind of a special case, because a lot of their weight is in interaction with the underlying OS native APIs and various conversions on that boundary.

So it may be a laggy or battery eating apps

Yup, it is pretty heavy, but virtual destructors are not the biggest reason for that.

You are a Qt moderator. Are we still good?

Sure, why wouldn't we? Just exchanging opinions. I have mine, you have yours, all good grease for interesting discussions :)
Moderator powers are granted here to keep order and ban spammers, not to be used as a discussion leverage, so don't feel discouraged from disagreeing if you feel strongly about your arguments. All moderators here are a chatty bunch from what I gather ;)

[JoeCFD]

@Chris-Kawa Agree. Discussions are good for everyone.

[JonB]

@JoeCFD
You have your opinions here, you are never rude! You have said nothing at all out of place here (or elsewhere) :)

[Kent-Dorfman]

This post is deleted!

[Kent-Dorfman]

there is ample valid information online about when and why you define a virtual destructor so I won't rehash here. Also, the generally accepted
"modern rule" is that there is a group of constructors and assignment operators where if you declare one them you should define all and provide concrete behaviour for them. That would be simple copy/assignment and move semantics.

[SimonSchroeder]

@JoeCFD said in is it possible to override destructor ? what care we have to take when we use it ?:

Qt uses virtual destructors all over the places across the framework.

There are several important reasons for this: The main reason why it started like this it most likely the age of Qt. Back then a lot of people would defend a pure OO approach. For pure OO it is mandatory to use virtual destructors. Bjarne Stroustrup himself pushes back to see C++ as a general purpose programming language and doesn't see a point in using it in a pure OO manner (because it hurts performance).

There is a second reason why virtual destructors are still used in Qt today. GUI frameworks lend themselves to consider the different widgets as objects. There is a heavy need to have a general widget as a base class and many different specializations. Because inheritance is used heavily it is mandatory to use virtual destructors. Any other approach would be way too complicated and error prone.

Should we be worried that Qt heavily employs virtual destructors? I personally think, no. The main reason to not use virtual destructors is performance. Computers are much faster than humans. For everything GUI-related you will normally not perceive the performance impact of virtual destructors as the GUI will be still faster than your perception. For every class you derive from Qt's widgets you will implicitly have a virtual destructor. So, the question if you should make all your destructors virtual by default does not arise in this context. It is still not a good idea to always make your destructors virtual because then they will also be virtual in performance critical code. Don't try to specialize on just the hammer if you have a full tool box. Instead learn when and how to pick the right tool.