QThread vs std::thread

QThread is not just a thread, it is also a thread manager. If you want your thread to play Qt, then QThread is the way to go. Qt is event driven, as is most of modern programming. That's a little more complex and flexible than "make a thread run a function".

In Qt, you'd typically create a worker together with a QThread, move the worker to that thread, then every function invoked by the event system for that worker object will be executed in the thread the worker object has affinity to.

So you can encapsulate your functionality in different worker object, say SafetyChecker, Printer, ServoDriver, JetDriver and so on, create an instance of each, move it to a dedicated thread and you are set. You still can invoke functions that would "block" instead of using fine grained events, and use atomics or mutexes to do inter-thread synchronization. There is nothing wrong with that, as long as you don't block the main/gui thread.

You would probably not want to do your printer code event driven, since in a multithreaded scenario that would involve queued connections, which are marginally slower than direct connections or even virtual dispatch. So much so that if you make your multithreading too fine grained, you are likely to actually experience a huge performance hit.

That being said, using Qt's non-gui stuff has its own merits, it will allow you to make a cleaner and more flexible design much easier, and you will still get the benefits of multithreading if you implement things properly. You can still use an event driven approach to manage the whole thing, it will be significantly easier than using only std::thread, which is a much lower level construct. You can use event driven approach to setting up, configuring, monitoring and managing the design, while the critical parts can be executed in blocking functions in auxiliary threads to achieve fine grained control at the lowest possible synchronization overhead.

To clarify - the answer does not focus on async task execution, because the other two answers already do, and because as I mentioned in the comments, async tasks are not really intended for control applications. They are suited to the execution of small tasks, which still take more time than you'd want to block the main thread for. As a recommended guideline, everything that takes more than 25 msec is preferable to be executed async. Whereas printing is something that may take minutes or even hours, and imply continuously running control functions, in parallel and using synchronization. Async tasks won't give you the performance, latency and order guarantees for control applications.

QThread is nice if you want to integrate the thread into the Qt system (like having to emit signals or connect to certain slots)

Though the layout of QThread is still made so it works with "old" c++. You have to create a class and all this overhead (code and typing wise) just for running in a thread.

If you just simply want to start a thread I think c++11 std::thread is less verbose/code you have to write. You can just use a lambda or function pointer and can give as many arguments as you want. So for simple threading I would suggest the c++11 threads over the QThreads.

Ofcourse it can be a matter of opinion which of those you prefer.

Though Qt has several different high level thread objects C++ does not. You may want to look into these if you need some of those instead of a basic thread or maybe you don't really need a basic thread at all but those suit you better.

Like a QThreadPool or simply a QTimer if you need to wait for things. Here is some readup about the alternatives in Qt to a bare thread.

QConcurrent also comes more close to c++11 future and async for example and has also optional threadpools where it can run.

The major problem with std::thread and QThread is that it does what it says on the tin: creates one thread for you, a thread that likely will do just one thing. Running a function "concurrently" using std::thread is very wasteful: threads are expensive resources, so creating one just to run some function is usually overkill.

While std::thread t1(&Class::function, this, ...) looks nice and all, it is usually a premature pessimization and suggesting it as some universal way of "doing things concurrently" is IMHO wrong. You can do better than that.

1. If you want to run a function/functor/method concurrently in a worker thread, use QtConcurrent::run or std::async.

   QtConcurrent::run uses the default thread pool by default, you can also pass your own instance of QThreadPool. A typical case would be to use the default thread pool for CPU-bound tasks, e.g. computations, image transformations, rendering, etc., and use a dedicated, larger I/O thread pool to do operations that are blocking due to limitations of the APIs you're forced to use (e.g. many database libraries only offer blocking APIs because their designs are fundamentally broken). Example:

   // interfaceQThreadPool * ioPool();// implementationQ_GLOBAL_STATIC(QThreadPool, ioPool_impl);QThreadPool * ioPool() { return ioPool_impl; }

2. If you want to have a QObject live in another thread (perhaps co-habitating with other objects), use QThread then move your object to that thread using moveToThread.

   It is an idiom to emit a signal from the worker thread to thread-safely pass data to the main thread. E.g. suppose you want to have a responsive GUI and wish to load images from disk in a worker thread:

   class MyWidget : public QWidget {  QLabel m_label;  ...  Q_SIGNAL void setImage(const QImage &); public:  MyWidget() {   ...   connect(MyWidget, &MyWidget::setImage, this, [this](const QImage & image){    m_label.setPixmap(QPixmap::fromImage(image));   });   QtConcurrent::run(ioPool(), [this]{ setImage({"/path/to/image.png"});  });  }};