[Interest] QThreads: There's no one way to "do it right"! :)

[d3fault]

I don't know what K. Frank is on but I advise everyone to disregard
his "advice". QThread::moveToThread(this) is a terrible idea
regardless of it not breaking most of the time.

Back on topic:
Both methods are "doing it wrong". Both require glue classes, else you
run the risk of breaking the "threads should manage their own
resources" rule of thumb.

QThread::run() glue class = the QThread itself
QObject::moveToThread() glue class = the worker object that gets moved
(if you DON'T pass in your [actual] worker through a glue class (the
glue class hasA your actual worker), your [actual worker's]
constructor won't be run on the target thread, breaking "threads
should manage their own resources")



I've been passively working on a design for an ideal 3rd method that
would make Qt's threading solution nearly identical to C++11's
std::thread [0], but instead of targeting a function it would target a
QObject's constructor (actually it could be any method, but the
constructor is my goal in order to have "threads managing their own
resources"). I've had minor success getting it to work WITHOUT any
arguments by using templates [1], but in order to support arguments it
'needs' (could be wrong) to be a moc/qmake hack.

I spent quite a few hours a while back reading the moc/qmake source
looking for the perfect place to put it, and it took me a while to
even understand what my problem was:

I need to generate a file WITHIN moc/qmake (based on looking for a
magic/macro string in each header/source file) that needs to then be
run THROUGH moc/qmake (because the generated file contains a Q_OBJECT
and uses signals).

Any moc/qmake experts know of a 'duh' solution to that problem? If so
we could end this debate once and for all by bringing Qt's threading
on par with C++11's std::thread solution.


d3fault

[0] - http://en.cppreference.com/w/cpp/thread/thread/thread
[1] - http://lists.qt-project.org/pipermail/interest/2012-October/004547.html