[Qt-interest] Threading and objects...

[K. Frank]

Hi Sean -

On Fri, Nov 12, 2010 at 9:06 AM, Sean Harmer
<sean.harmer at maps-technology.com> wrote:
> Hi,
>
> On Friday 12 November 2010 13:46:22 K. Frank wrote:
>> Hello Sean and Everyone -
>> <sean.harmer at maps-technology.com> wrote:
>> > On Thursday 11 November 2010 16:54:36 BRM wrote:
>> >> I have been doing quite a bit of multithreading with Qt for a while; and
>> >> ...
>> > The approach that I normally take to this is to have a trivial subclass
>> > of QThread that contains as members pointers to the one or more objects
>> > that actually do the work in the context of the thread.
>> > ...
>> On the  other hand, why not...?
>>
>> First, what your doing seems to make good sense, and is nice and
>> organized -- my question is about mulling over alternatives, and is
>> not to suggest that your choice isn't as good or better.
>>
>> So, why not subclass QThread to give it the functionality of its primary
>> worker object, and moveToThread it to itself when it's instantiated,
>> presumably in its constructor, or something?
>>
>>    auto workerThread = new DoSomeWorkThreadSubcalss;
>>    workerThread->start();
>
> I guess it's just how I visualise the concepts encapsulated by QThread. I tend
> to think of QThread as a class to manage a thread rather than as a way of
> doing work within that thread.
>
> The main advantage to me is that it keeps the conceptual model clearer in my
> (little) brain ;-).
>
> It also allows me to reuse the worker objects in the main thread or in some
> other worker thread that also uses additional objects without being tied into
> a specific QThread subclass and then havong to refactor things later.
> ...
> Coupling the worker object logic into the QThread subclass is perfectly
> reasonable of course but if designing a library then I like to be able to
> reuse things in a differently threaded context.
> ...

Yeah, makes sense -- a classic separation-of-concerns issue.

Thanks.


K. Frank


> ATB,
>
> Sean