[Solved] Objects Live Cycle
-
Dear All:
I have a question, what is the live cycle of a QWidget Objects? Do I have to call delete buy myself or the object is deleted as soon as the Parent Widget is delete? When the Parent Widget delete it it said the pointer to null?
Best and thanks
-
[quote author="epalmero" date="1417614712"]
I have a question, what is the live cycle of a QWidget Objects?[/quote]
It is not only QWidget objects. Any class derived from QObject may be part of an object tree. "Here":http://qt-project.org/doc/qt-5/objecttrees.html is some info about QObjects.[quote author="epalmero" date="1417614712"]
Do I have to call delete buy myself or the object is deleted as soon as the Parent Widget is delete?[/quote]
A parent QObject will delete it if you provided a pointer to a parent when you instantiated a QObject derived class.[quote author="epalmero" date="1417614712"]When the Parent Widget delete it it said the pointer to null?[/quote]
Even if parent set its pointer to null it will not be visible in your code.
Parent object has its own variable that points to the same object and this variable is not the same as a pointer in your code.
-
What about if I send the QObject as a child for example what habppen if i set a Qwigdet as a central widget in a QmainWindows? Do I need to delete that object? I have created that QWidget without QMainWindows as a parent?
Thanks for your help help
Ernesto
-
According to the "doc":http://qt-project.org/doc/qt-5/qmainwindow.html#setCentralWidget "QMainWindow takes ownership of the widget pointer and deletes it at the appropriate time."
So you don't need to delete it. QMainWindow will do it.
-
There are couple other ways a widget can be deleted:
- (obviously) by placing the widget on the stack. It will be deleted when it goes out of scope. Don't give widgets placed on the stack parents, as it will lead to double-delete bug and crash your app.
- manually, by calling delete on dynamic object.
- by setting a parent. If a widget has parent set then the parent will delete all its children when it is deleted
- by setting "WA_DeleteOnClose":http://qt-project.org/doc/qt-5/qt.html#WidgetAttribute-enum attribute on the widget. When this attrib is set Qt will automatically delete this object when the close event is accepted.
Some other informations to reiterate:
When you put a widget in a layout or set it as a central widget in QMainWindow or use it as a cell widget in a table etc it is automatically re-parented and deleted when the parent goes away. Docs often state that but not always. You can assume that. When it is not the case the docs will clearly state that eg. "adding a QAction to the widget":http://qt-project.org/doc/qt-5/qwidget.html#addAction does not re-parent the action.If you want to keep track of when a widget is deleted keeping a pointer to it is not enough. This is c++. It will not zero the pointer when the thing it points to is deleted.
To keep track when a widget is deleted you can connect to the destroyed signal of that widget. Another way is to create a QPointer to that widget. It will be, in contrast to raw c++ pointer, zeroed when the object it points to is deleted.
-
Great explanation. Thanks Chris Kawa.
I think this answer is good candidate for a Wiki article.
-
Dear Chris Kawa:
Thanks very much for your help this is really crystal clear. I am typically use std::shared_ptr in my classes when I use C++11 but I think QPointer will be the equivalent here except that I will check if it is zero.
Again thanks a lot for your help
Ernesto
-
std::shared_ptr serves very different purpose. Its equivalent in Qt is QSharedPointer.
They both manage the lifetime of an object. The last instance of the shared pointer deletes the object.
QPointer is very different. It does not manage the lifetime of an object it points to. It only gets set to 0 when the object is destroyed, something that neither std::shared_ptr nor QSharedPointer do.
-
Thanks very much for this clear answer this is really what I was looking for.
