[Development] What kind of airplane we want to build?

[Bubke Marco]

On January 21, 2016 1:28:58 AM Marc Mutz <marc.mutz at kdab.com> 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 <marc.mutz at kdab.com> | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

--
Sent from cellphone, sorry for the typos