On 10/23/12, Alan Ezust <alan.ez...@gmail.com> wrote: > > http://www.ics.com/designpatterns is one place where you can see the book's > contents and download the code examples. It requires you to register/login > but it's free. >
Which example are you referring to? Life or PrimeThreads? I read the whole chapter on QThreads and QtConcurrent... I stopped reading Life's source when you called QtConcurrent::blockingMappedReduced from the main window class (these aren't the designs I'm looking for). I am pretty sure the reason your QtConcurrent version of PrimeThreads is significantly faster than the QThread version is because: a) QtConcurrent pre-generates the list of numbers to check against ahead of time b) The QThread version QMutex-grabs the next number each time c) Generating prime numbers scales horizontally... though I guess your for loop generating QThreads should too... so maybe (c) shouldn't be here I'm inclined to believe that QtConcurrent::filter() uses something similar to QMutex behind the scenes... but maybe not? Maybe QtConcurrent::filter() is more optimized while still providing similar functionality (without using QMutex specifically)? I don't know how it's implemented. However the tests already don't seem fair. For the example I'm creating I am not demonstrating resource sharing so I'm not going to use QMutex anywhere... and I can't determine a reason that a single long running (non-horizontally-scaling) backend would benefit from using QtConcurrent (especially since with QtConcurrent it will just be 1 QThread pulled out of a QThreadPool anyways, right?). I was hoping for the tl;dr answer... but your book is a good read either way :-P... On 10/24/12, Bo Thorsen <b...@fioniasoftware.dk> wrote: > Hmm, not sure. It looks to me like the problem is again just moved > somewhere else. The "Would be dangerous to call methods" comment shows > this problem. Using a QThread is difficult to get right, so by trying to > hide this fact, you could end up giving the impression that it isn't. I > usually prefer exposing the problems to the developer, unless they can > be removed by a helper class. In some cases you can do this, in the > general QThread case you can't. Otherwise it would already have been done. > Threading in general has a million ways to mess something up. That stack-object-within-run design is the best one I've read/thought-up so far. If you have any better suggestions, I'm all ears. That's the purpose of this thread. Adding a note in the docs saying not to call methods directly on the object emitted via readyForConnections() is far better than most solutions. It's already ridiculously easy to screw up overriding run() or moveToThread() as it is. The signal name itself "readyForConnections" will be constantly reminding the user of it's purpose, lessening the chance that they'll screw up it's usage by calling a method on it directly. Definitely getting ahead of myself with this question: is there a way to use templates with a variable amount of T's? Sort of like those ellipses in method parameters? I'd also need a variable amount of parameters for my readyForConnections() signal (*gasp*, famous last words?)... it would emit the types as parameters in the same order I pass them in to the template. ^What I'm trying to accomplish with that is: run() { UserObject1 obj1; UserObject2 obj2; emit readyForConnections(&obj1, &obj2); exec(); } ...etc so I can have N amount of objects on the thread. Already pretty sure I can do it with just 1 template type (haven't tested lol). I'd also want to stay C++ 98 compliant. MOC can definitely do this :). At least hackily (signals/slots are hacks imo... just really amazing ones!!!). For now I still think just with a single T it's a pretty sweet/clean design. I hope I don't run into unforeseen problems during the rewrite =o. d3fault _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest