The correct way of instantiating the main widget in main.cpp
-
Hi all,
In Qt programs we mostly have two options either to normally instantiate the main widget or dynamically using
new
.For instance:
int main(int argc, char *argv[]) { QApplication app(argc, argv); QSuperClass* myWidget = new QSuperClass; myWidget->show(); // or QSuperClass myWidget; myWidget.show(); return app.exec(); }
I know the former is allocating memory dynamically (on heap) and the latter is doing the same thing manually (on stack), but when or where do we generally prefer one over another, please?
Thanks in advance.
-
The first leaks QSuperClass (unless you set Qt::WA_DeleteOnClose), the second may lead to problems when your QSuperClass dtor calls something which needs the eventloop (e.g. a deleteLater()).
My usage in real application looks similar to
int main(int argc, char *argv[]) { QApplication app(argc, argv); int ret = -1; { std::unique_ptr<QSuperClass> myWidget(new QSuperClass); myWidget->show(); ret = app.exec(); } return ret; }
-
Hi
In main, the stack version is preferred
as it guarantees automatic clean up.
However, both could work and it's hard to say one is
more correct than the other. -
@Christian-Ehrlicher said in The correct way of instantiating the main widget in main.cpp:
may lead to problems when your QSuperClass dtor calls something which needs the eventloop
@Christian-Ehrlicher said in The correct way of instantiating the main widget in main.cpp:
My usage in real application looks similar to
How does your usage fix the problem you raised?
I always use the stack version but if we want to be anal about this shouldn't it be like the below?
QSuperClass* myWidget = new QSuperClass; myWidget->show(); QObject::connect(&app,&QCoreApplication::aboutToQuit,myWidget,&QObject::deleteLater); return app.exec();
-
@J.Hilk said in The correct way of instantiating the main widget in main.cpp:
it gets destroyed once app.exec returns and therefore deletes the object its pointing to
it gets destroyed
onceafter app.exec returns and therefore deletes the object its pointing to.So if
~QSuperClass
callsdeleteLater
on some object that is not a child (or grandchild, etc) ofthis
it will be leaked as correctly pointed out bu Christian -
Thank you all,
I got some part of the subject but not all since there're sophisticated matters and need more experience to spot them appropriately.To sum up, we had better use the stack version unless we are too strict to pick out heap, and in this case, the version suggested by @VRonin is to be used.
Right until here?So the next question is "when" will we be logically forced to use the heap version?
PS: I became slightly glad that I found somewhere in Qt where C++ smart pointers are used advantageous! But likely they're still a de facto redundant item to Qt.
-
@tomy said in The correct way of instantiating the main widget in main.cpp:
But likely they're still a de facto redundant item to Qt.
Not at all.
next question is "when" will we be logically forced to use the heap version?
If you do weird stuff in the destructor of objects created in
main()
then use the heap version -
If you do weird stuff in the destructor of objects created in
main()
then use the heap versionI will keep that in mind for further uses in the future to get more used to those "weird stuff".
Not at all.
But you wouldn't use them in the example above.
Will you please tell me, or better give a "simple" example, where a smart C++ pointer is used preferably, in a Qt project.
-
@tomy said in The correct way of instantiating the main widget in main.cpp:
But you wouldn't use them in the example above.
No, because at the end of the day it's the same as stack allocation
Will you please tell me, or better give a "simple" example, where a smart C++ pointer is used preferably, in a Qt project.
Private implementations are the typical example of how to use of smart pointers in Qt. Basically if the class is not a subclass of
QObject
and you have to allocate on the heap you should probably think about using smart pointers