I doubt you can get out of this issue. QApplication wants to be in
control of the main loop, and it wants to do so from the main thread.
Failing that, you'd need to integrate the host application's event loop
into Qt's event loop, and still have a way to cal QApplication::exec()
on the main thread. If your host application does not allow for those
two things, I'd say there's nothing you can do.
On 16/03/16 17:42, Nuno Santos wrote:
Nikos,
Thanks for your reply.
The problems is that host application hangs forever if I don’t delete it
and crashes if I delete it. I’m in a kind of dead end.
Any ideas?
Thanks
Nuno
On 16 Mar 2016, at 14:07, Nikos Chantziaras <rea...@gmail.com
<mailto:rea...@gmail.com>> wrote:
On 16/03/16 14:01, Till Oliver Knoll wrote:
I don't think you're supposed to delete qApp
Actually you do need to delete it. Most people don't because after
qApp->exec() returns, the program ends anyway. But if you want to have
0 leaks, you need to delete your QApplication instance.
Usually you don't delete qApp directly, but just your instance, but
that's the same thing, really:
int main(int argc, char** argv)
{
QApplication app = new QApplication(/* ... */);
app->exec();
delete app;
// or:
// delete qApp;
// which does the same thing.
}
In normal applications, like the above, deleting it is redundant.
You're exiting the process, so the environment is going to clean your
memory anyway. It's still a memory leak, if you're pedantic about it.
If you're using QApplication in a plugin, deleting qApp is actually
mandatory, otherwise you're leaking the qApp instance when the plugin
unloads; no one else is going to delete it for you.
_______________________________________________
Interest mailing list
Interest@qt-project.org <mailto:Interest@qt-project.org>
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
