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

JoeCFD

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

Chris Kawa

In VS, virtual is added to all destructors automatically when new classes are created

No, it's not.

add virtual to all of your destructors and make it a habit.

That's a terrible advice! Why would you recommend that?
Destructors only need to be virtual when they have a need to be virtual. Virtual destructors ensure that objects are destroyed polymorphycally i.e. calling delete on base class pointer will call derived class' destructor first. That's it. This is not always needed and has a cost in the form of vtable call. You should only pay that cost when you need that functionality, not out of habit!

JonB

@Chris-Kawa
I clearly need to read up on this! I am not understanding when you are saying I should vs should not go for a virtual ~ :)

What do I need to read (preferably simple!)?
I may be mistaken, but I believe if you let Creator generate your widget class it puts in an empty virtual destructor automatically? Why that? [Oh, maybe it's not empty, it will have that delete ui statement. OK, but they mark it virtual, right?]

Chris Kawa

@JonB said:

What do I need to read (preferably simple!)?

For the gist of it this example is enough:

class Base() {};

class Derived: public Base
{
public:
    ~Derived() { /* delete something */ }
};

int main()
{
   Base* foo = new Derived();
   delete foo; // Oh no! ~Derived is not called and something leaks. Should've used virtual!
}

if you let Creator generate your widget class (...)

Widgets are derived from QObject, which is a polymorphic class with virtual destructor, so any derived class has a virtual destructor whether you specify it or not. Creator puts it there just to be explicit, for readability sake.

As to when you should make destructor virtual? When you expect your class to be derived from and have polymorphic behavior. To explain it with examples: QObject is expected to be derived from and derived classes often deallocate resources in their destructors, so polymorphic destruction behavior is indeed very much desired here, and lack of it would lead to leaks and broken behavior.
On the other hand a value-class like QPoint has no business being derived from and there's no excuse to pay for virtual destructor call in its case, so it doesn't have a virtual destructor. Sure, you can shoot yourself in the foot derive from it and deallocate some dynamic resources in the derived destructor, but honestly that's on you for using it that way. There's even a protection for that in the language - you can make your class final and make sure nobody abuses it this way.

Consider this:

class Point2D
{
public:
   int x = 0;
   int y = 0;
};

class Point3D : public Point2D
{
public: 
   int z = 0;
}

Even if you do

Point2D* p = new Point3D();
delete p;

nothing is leaked. There's absolutely no need here for vtables cost associated with them.

JoeCFD

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

When you expect your class to be derived from and have polymorphic behavior.

When you expect your class to be derived from and have polymorphic behavior. <===I think it is better to prepare for the unexpected. When all coders know what to expect, there may not be any bugs anymore. What is the cost of triggering virtual destructor call in a GUI application? In a large project, people can easily embed mines by not setting destructors to be virtual.
And often when a destructor is created(needed), programmers want to clear certain things in it. Then I do not understand why not to call it when its parent classes are destroyed.

Chris Kawa

What is the cost of triggering virtual destructor call in a GUI application?

Well, first of all C++ is not just about GUI applications (it's the minority of them really). But even in GUI apps you can face a task that requires a bunch of objects destroyed, for example point clouds, large number of database entries etc. It adds up. It might not mean much in a calculator app, but you mentioned good habits, so one of them is minding performance, even if it's not the most critical aspect of given task.

I think it is better to prepare for the unexpected

You can't, if you do it becomes expected :)
In all seriousness defensive programming has its uses of course, but it depends on your priorities. In mission critical software it might be desirable but in high performance or energy conservative scenarios it is the worst. And who likes laggy or battery eating apps? ;)

Kent-Dorfman

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

I heard from many place that in c++ constructor overriding not possible.

This is just untrue. Any time you subclass something you have a choice when you create the subclass constructor: ignore the base class constructor (usually a bad idea) or add the base class constructor in the initializer list.

struct base {
explicit base() {}
};
struct subclass: public base {
explicit subclass(): base() {} // calls base() then does subclass initialization
};

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.