On January 21, 2016 1:28:58 AM Marc Mutz <[email protected]> wrote: > On Wednesday 20 January 2016 21:52:49 Thiago Macieira wrote: >> On Wednesday 20 January 2016 21:08:07 Pau Garcia i Quiles wrote: >> > Replacing QThread with std::thread? Please don't. >> >> Unlike the containers or even futures/promises vs QtConcurrent, we can >> easily argue that QThread provides a lot more functionality than >> std::thread. In just one word: signals. > > What happened to "you're doing it wrong!"? :) AFAIU that blog post, you're > supposed to use the signals of QObjects living in that thread, not the > QThread > itself. > > And that's perfectly possible with std::thread, too: > > auto po = new ProcessingObject(); > connect(po, ...); > po->moveToThread(nullptr); // enable "pulling" moveToThread() > auto t = std::thread([po, gui = QThread::currentThread()]() { > QEventLoop loop; > po->moveToThread(QThread::currentThread()); > connect(po, ..., &loop, &QEventLoop::quit); > loop.exec(); > po->moveToThread(gui); > // or: delete po; > } > > Am I missing something?
The question is if you really want an event loop here. Mostly I want a command queue where I can prioritize and merge the commands. I want to poll for cancel commands without much overhead and it should support move only types. I really think we should step back and look at the broader picture before we apply our tools. >> We should provide QThread::makeThread() taking a lambda and some other >> niceties, though. > > -- > Marc Mutz <[email protected]> | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development -- Sent from cellphone, sorry for the typos _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
