[SOLVED] A pair of questions

  • I've ported my application to Qt using widgets, everything seems to be working fine so far. However, there are still a few things bothering me. Using Qt creator.

    1. When I close my application I see this message in debug output: "QThread: Destroyed while thread is still running". I haven't noticed any kind of weird behaviour, should I bother fixing it? I've tried to close thread before exiting application but that didn't work. I've used closeEvent inside MainWindow with QThread::quit() and QThread::exit(). This message is caused by an infinite loop created through subclassing QThread.

    2. I have organized my project into various folders through using .pri files. There are few things that I dislike and would like to avoid:

    • Is specifying SOURCES and HEADERS inside .pri and .pro files mandatory for a Qt project? I have my own way of organizing the project, most of the time I want .cpp and .h to be shown together and not within different folders.

    • Let's say I have folder 1 and folder 2. Inside folder one there is "myclass.h". To include "myclass.h" inside a file within folder 2 I have to write #include "folder_1/myclass.h". Is there any way to make it just #include "myclass.h"?

  • Moderators

    1. quit() and exit() only exit Qt event loop of the given thread if you're running one. If, on the other hand, you've got something like while(true) {...} they do completely nothing. The proper way to do this is to signal the thread that it should finish e.g. set an atomic flag and change while(true) to while(!flag). Then, in the main thread, set the flag and wait for the thread to finish using "wait()":http://doc.qt.io/qt-5/qthread.html#wait.

    2. This is just how Qt displays qmake project contents.
      To include a header directly, without specifying the folder, provide that folder path to the INCLUDEPATH in the .pro/.pri file.

  • Thanks! Problems solved.

    [quote author="Chris Kawa" date="1425324850"]
    ...This is just how Qt displays qmake project contents...

    That's a pity. Not a big deal, but still a minor annoyance. Is it development paradigm or rather an oversight? I think in general Qt Creator could be a bit more flexible and intuitive in terms of project organization, though maybe it's just my lack of experience with it so far.

  • Moderators

    This is a sort of view filter. It groups files by types inside projects and sub-projects.
    You can play around with options above the project view: "simplify tree" or switching Project view to file system view, although it's not exactly what you want.
    From my own experience the most productive way to navigate project is via the locator (Ctrl + K) and keyboard shortcuts. there are a couple of muscle memories to develop but once you do you can go really fast.

  • Thanks, I'll have a look at it. Ctrl + K seems like a really good navigation feature indeed.

    EDIT: forgot to ask a question. Just curious, what kind of bad things can happen, if an application shuts down while thre are threads still running? What if a running thread is destroyed while application is still active?

  • Moderators

    Unless you're doing some really crazy stuff the OS should be able to clean up if you leave some mess. By that I mean any OS handles to files, sockets etc., but you should definitely clean these up yourself if you can.

    But still, you can leave a mess for other apps if you are using something like QSharedMemory and don't clean up properly.

    In terms of your own data things might not look so bright. If the running thread did some IO at the time or was writing something to sockets or registry you're looking at corrupted or garbled data. Also I'm not sure IO buffers are flushed before such forced close.

    As for what happens inside your own app when you terminate a worker thread forcibly things get even worse. If the thread was accessing any objects at the time you're again looking at data corruption. Invalid pointers, objects in indeterminable state, partially modified fields, general garbage in variables shared between threads. stuff like that..

    In general it's almost never a good idea to forcibly terminate a thread. Signal it to finish on its own (do cleanup, stop IO, close handles etc.) and wait for it.

  • Interesting, I'm glad I've fixed it now. Thanks for the help!

Log in to reply

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.