8

I'm considering two options to run asynchronous code: Qt Concurrent and std::async. Given that I'm writing a GUI app with Qt, it makes sense to go with Qt Concurrent. However std::async also seems good and supported by all major compilers.

Should I use Qt Concurrent or std::async for new code? What else should I look for when comparing the two?

László Papp
  • 51,870
  • 39
  • 111
  • 135
galymzhan
  • 5,505
  • 2
  • 29
  • 45

2 Answers2

7

Given that I'm writing a GUI app with Qt, it makes sense to go with Qt Concurrent

I would say, it is not so simple. I would personally utilize the standard library as much as I can. However, there are constraints to take into account:

Do you need to support your software on platforms not supporting at least C++11?

If the question is yes to that, using Qt solutions is a better option in a Qt based software. That being said, even for that, you could have different Qt solutions depending on your need. One is the thread weaver from KDE, but let us not go that far for now...

Another question, that you could ask from yourself:

Do you already have an existing code base where that is used throughout?

Depending on the answer, this could also provide further aspect for the decision, whether you prefer consistency, or forward thinking.

There is also another question here to be asked:

How much of QtConcurrent do I need?

Depending on the exact answer, it may or may not be a better alternative. Note that, not every functionality of QtConcurrent is in the standard library just yet, for instance something like QFutureWatcher with the Qt signal-slot mechanism.

So, yes, as a Qt user, I would suggest to use the standard library as much as possible. These days, Qt even explicitly depends on them, so will not run on platform not supporting it. Also, the general direction put seems to be this in Qt Project proper. For instance, lots of stuff got obsoleted in the QtAlgorithms, but that is just one of those.

László Papp
  • 51,870
  • 39
  • 111
  • 135
3

Qt Concurrent lets you run a function in another thread using QtConcurrent::run(). So i think you can only compare QtConcurrent::run() with std::async.

Qt Concurrent is so sophisticated and has many useful features. It includes APIs for parallel list processing and lets you create multi-threaded programs without using low-level threading primitives such as mutexes or semaphores. It also adjusts the number of threads used according to the number of processor cores available.

I think using Qt Concurrent is so cool because of its high-level APIs and ease of use.

Nejat
  • 31,784
  • 12
  • 106
  • 138
  • 2
    The OP could also compare QFuture with std::future, and the rest with std::promise, std::packaged_task, shared_future, etc. None of these will require low-level threading primitives on their own like mutex and semaphore. – László Papp Apr 21 '14 at 10:01
  • @Ipapp Indeed. QtConcurrent is also recognised by the developers themselves as being unmaintainable. Last time I checked, they were considering taking in KDE's ThreadWeaver library which is a cross-platform task based concurrency library and much easier to write for. They were also considering writing another library that would influence the std library and perhaps get that into the standard. – Paul-Sebastian Manole Jan 19 '18 at 06:56
  • @brokenthorn Can you add a reference to back up your statement? – m7913d Jun 15 '19 at 14:27
  • 2
    @m7913d, well there was [this](https://bugreports.qt.io/browse/QTBUG-3315). And then there were these from the developer's mailing list: [1](http://lists.qt-project.org/pipermail/development/2012-November/007921.html), [2](http://lists.qt-project.org/pipermail/development/2012-November/007952.html), [3](http://lists.qt-project.org/pipermail/development/2012-November/007901.html). Sorry but I haven't kept up with Qt these past years. – Paul-Sebastian Manole Jun 18 '19 at 08:13