On 15 November 2012 04:31, Sune Vuorela <nos...@vuorela.dk> wrote: > On 2012-11-14, Christian Kandeler <christian.kande...@digia.com> wrote: >> On 11/14/2012 12:17 PM, Sorvig Morten wrote: >>> QtConcurrent is done. The implementation is not good enough to be used as a >>> base for further development. >> >> Can you be a bit more specific? What are the general problems and why >> can't they be easily solved? > > I think it is quite limited and hard to use. I recently tried and after > giving up on that, I switched a project to the ThreadWeaver library by > KDE which not only made my code simpler, it also made it much easier to > understand and having threading cote separated out. > > The ThreadWeaver library is a quite simple, but yet powerful thing built > on qtcore.
Thiago also hinted that QtConcurrent development is being minimized ("...we're not developing QtConcurrent anymore and shouldn't be spending any effort on this than necessary to keep it working" [1]). That suggests that the dev team has reached a dead end with the code -- although the problems aren't immediately obvious to outsiders. If the quality of QtConcurrent is subpar and there's little chance of improving, then I think it's important to let Qt users know that -- through documentation and/or deprecation -- so that they don't unwittingly invest their resources in stagnant technology. The current impression I get from the official documentation is that QtConcurrent is a high-level alternative to QThread and QRunnable. QtConcurrent offers the ability to run a function in parallel, and to process a container's elements in parallel. The former can be replaced by QRunnable to an extent... but what about the latter? Are there strong use cases for parallel container processing, and is it worth salvaging that functionality? Sze-Howe [1] https://codereview.qt-project.org/#change,39375 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development