is it possible to override destructor ? what care we have to take when we use it ?
-
@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 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 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 ;) -
@Chris-Kawa Agree. Discussions are good for everyone.
-
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.
This post is deleted! -
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. -
@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 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.
