On Thu, Jan 3, 2019 at 4:17 PM Roland Hughes <rol...@logikalsolutions.com> wrote:
> > On 1/3/2019 4:00 AM, Konstantin Shegunov wrote: > >> Yes QApplication destructor is invoked last..Does it makes sense to use > >> deleteLater() in the widget destructors instead of existing delete if it > >> could be cleaned up as part of qApp-quit()? > >> > > Your example code clearly shows otherwise. You have a QObject that's > > created before and destroyed after the application object. > > Wow! > > Perhaps a better question would be, "How is it that doesn't fault today?" Just wondering if the test compilation "worked" due to luck of the draw. > I don't know, I'm not intimately familiar with all the internals. QObjects, I think, rely/relied on a global state that's initialized in QCoreApplication. What I can say for sure is that thread information is initialized by the application object. Just for illustration purposes, this is also the reason why you can't run a QThread and have the application object in its QThread::run override. The thread object is going to set up the global thread info and then you're going to get weirdness - warnings such as "Not creating the application object in the main/GUI thread". Possibly segfaults at exit. If you actually need to do such stuff you really need to spin a system thread (std::thread, pthread, w/e) and then create the application object (besides issues you have with the event loop integration on osx). So, even if it worked before, it had been wrong all along, so it should be fixed anyway.
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
