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

[Francisco Gonzalez]

2012/10/24 d3fault <d3faultdotxbe at gmail.com>:
>
> Weird, so what you're saying is:
>
> QWidget 'this' parent
> _Layout
> _Layout1Widget1
> _Layout1Widget2
> __SubLayout1 // added via Layout.addLayout(), Layout now being his parent
> _SubLayout1Widget1
> _SubLayout1Widget2
> __SubLayout2 // ditto
> _SubLayout2Wiget1
> ___SubSubLayout3 // added via SubLayout2.addLayout(), SubLayout2 now
> being his parent
> _SubSubLayout3Widget1
> _SubSubLayout3Widget2
>
> With everything that's a widget being a sibling and a direct child of 'this'?
>
> I guess that makes sense. I think I'm better off just removing the
> part of the comment that's wrong than trying to explain that (but the
> QWidget::setLayout docs should (and don't) explain it!).
>

Look at http://qt-project.org/doc/qt-4.8/layout.html#tips-for-using-layouts


>
>>
>> Regarding rewriting the example, I think the best way to rewrite it is to
>> remove all usage of QThread entirely, and see if you can figure out how to
>> program it using the higher-level QtConcurrent  API. In my book [Intro to
>> Design Patterns in Qt, 2nd edition], I show another multithreaded example
>> written both ways and the QtConcurrent version performs much better.
>>
>
>> book
> I wish I could see what you're talking about :-P. My goal in making
> that example is/was to have a simple and easy to understand reference
> that implements a clean and re-usable design. Performance was not a
> huge concern, but I wouldn't say it isn't important.
>
> Why would QtConcurrent be more performant if they both use QThreads in
> the background? I'm under the impression that QtConcurrent is meant
> for.. err... problems... that scale horizontally. Yes my use of
> QCryptographicHash would scale horizontally, but not everything can.
> Is QtConcurrent still more performant in those cases where we can't
> scale horizontally? If so, I'll look more into rewriting it under
> QtConcurrent (if I could see the example in your book I could answer
> this myself).
>
> At a glance (I've read all the QtConcurrent docs previously, but have
> yet to actually use it... so I guess I should say "at a re-glance"),
> it looks like I could use that template-based readyForConnections()
> emitting design described in my previous email very easily within
> QtConcurrent::run(). However, then I saw this: "Note that the function
> may not run immediately; the function will only be run when a thread
> is available" (
> http://qt-project.org/doc/qt-4.8/qtconcurrentrun.html#run ). Within a
> large application with many backend objects/threads (doing different
> things, so they can't scale horizontally), it sounds sub-optimal to
> not be able to have them all running at the same time. You could
> override QThreadPool's max thread count, but idk that just seems
> hacky. Aren't thread pools meant for numerous shorter living units of
> execution? I recall reading somewhere something along the lines of "if
> you are going to keep the thread alive for a long time, use QThread
> instead". The example, and the design I'm trying to perfect, is the
> long-standing single (or I guess double lol) backend thread.
>
> If I'm wrong and setting QThreadPool's max thread count to be >= your
> backend object count on a per-project basis isn't a dirty hack
> (separation of concerns!)... and if QtConcurrent really performs that
> much better... I'll probably use it for the rewrite. Thanks :)
>
> d3fault
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest