[Interest] Heavily Commented Example: Simple Single Frontend with Two Backends

[Daniel Price]

The problem with the subclassing pattern is that you end up with an object spanning two threads. You class is instantiated in the main thread (along with it's member data) but run(), when called, is operating in a different thread. It's all too easy to get into a mess doing this.

You should look into the active object design pattern. The idea is that you hide the object that lives in another thread behind a managing object. I only discovered this recently and it's vastly superior to subclassing QThread, or using moveToThread or any of that rubbish. In fact, I don't use QThread at all these days; C++11 (and boost if you don't have C++11 yet) has a better threading model.

From: interest-bounces+daniel.price=fxhome.com at qt-project.org [mailto:interest-bounces+daniel.price=fxhome.com at qt-project.org] On Behalf Of Bo Thorsen
Sent: 22 October 2012 06:40
To: interest at qt-project.org
Subject: Re: [Interest] Heavily Commented Example: Simple Single Frontend with Two Backends

Den 21-10-2012 23:46, d3fault skrev:

On Oct 21, 2012 11:02 AM, "Bo Thorsen" <bo at fioniasoftware.dk<mailto:bo at fioniasoftware.dk>> wrote:
>
> If you set out to correct the documentation, you should make it better,
> not go from one one-sided way of thinking to another.
>

What? Are we talking about the same thing? 99% of the time, implementing QThread and overriding run() is not what the user wants to do... but that's what the (currently being revised) documentation suggests. Sure it's not completely wrong... but that method should be just barely mentioned, and only after the better usage (moveToThread) is thoroughly explained. There are too many people "doing it wrong" (to quote that one article).

See, this is where you are wrong. I've heard this claim over and over again, and that doesn't make it right. Saying that subclassing is only valid for 1% of the time is just silly. There are plenty of perfectly fine reasons to do this.

1) If you have pure computations (emitting progress signals can take it off the list)

2) If you have initialization that has to run in your thread, one way is to do a run method like this:

run() {
  init();
  createObjects();
  exec();
}

3) moveToThread has problems as well. The worst of them: thread->moveToThread(thread). I have actually seen this in customer code.

4) By letting the thread instantiate it's object, you probably have better separation of responsibility. With moveToThread, you don't just start something where you don't need to know how it's implemented. That's bad OOP style.

Now, please understand what I'm saying. I do the moveToThread way more than half the times I use threads, so I agree that it's better in most cases. The only thing I'm saying here is that when you claim that subclassing is wrong 99% of the time, that's waaaaaaaay off the mark. It's a valid tool in the toolbox.




Bo Thorsen.



Come by my DevDays talk in Berlin - "Designing for testability". Learn how to build and run your unit tests with the Qt application.



Fionia Software - Qt experts for hire.

________________________________
This email is confidential. It may also be privileged or otherwise protected by work product immunity or other legal rules. Errors and Omissions Excluded. If you are not the intended recipient please notify the sender. Please delete the message from all places in your computer where it is stored. You should not copy the email or use it for any purpose or disclose its contents to any other person. To do so may be unlawful. Email is an informal means of communicating and may be subject to data corruption accidentally or deliberately. For this reason it is inappropriate to rely on advice contained in an email without obtaining written confirmation of it first.

FXhome Limited is a limited company registered in England and Wales. Registered number: 04172812. Registered office: Suite 4 St Giles House, 27 St Giles Street, Norwich, Norfolk, NR2 1JN, U.K.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20121022/978d11bc/attachment.html>