

C++0x support in Qt - guruz
http://labs.qt.nokia.com/2011/05/26/cpp0x-in-qt

======
danieldk
Interesting, one wonders if there will be some de-duplication in the far
future. There is a lot of overlap with TR1, for instance Qt's smart pointer
and container classes.

On the other hand, I guess many Qt users will treat Qt as the C++ standard
library ;).

~~~
dkersten
I do a lot of C++ Qt programming and I often have a hard time deciding if I
should use. The most common is should I use QString for in my code easy
interaction with Qt, or std::string for easy interaction with other, non-Qt,
libraries that I use?

I also sometimes wonder what I should use when I do multithreaded stuff (which
I often do, because I like multicore stuff) - for example, if I want heavy-
weight threads (as opposed to tasks, which I always use Intel Threading
Building Blocks for), do I use C++0x? Do I use QThread? Do I use the TBB
threads wrapper?

If I am not using third party libraries, I do prefer to use Qt over the
standard library, simply because it keeps everything consistent (less
conversion between std::x and Qx)

~~~
cheez
Outside of basic windowing functions, Qt is pretty awful. I don't even use
their widgets unless I am creating a form UI or a normal widgety app. I
basically use Qt as a gigantic wrapper around native GUI event loops.

I only use QThread if I need to do QImage stuff in a thread (I think this is
strictly not necessary, but safer imo).

Conversion between QString and my::string are there but I have not found them
to be very problematic. I guess it depends on how often you are doing these
conversions.

In short: Qt sucks, but like democracy, it's the best of the worst.

~~~
guruz
Can you go into details why it sucks?

~~~
cheez
Main reasons:

1\. Implementing models are way too complicated.

2\. The widgets are very limited. For example, the table view requires hacks
to support clickable links. Not custom delegates or label but hacks. HTML/JS
widgets are way more flexible than Qt widgets. That says a lot.

In general, if you're trying to make a really usable app, Qt widgets just get
in the way. If you're trying to make a regular ol' form-based UI, with perhaps
a OpenGL viewport for the real fancy stuff, it's actually perfect.

What I end up doing is using Qt for the event loop and window management, but
do everything else myself except where it's obvious that Qt can handle it.

There are very few apps where you need to do this kind of thing though, so for
the majority of people, it's actually OK.

Also, QML is a pretty awesome technology. I'm looking at how to use it to
speed up development.

Edit: I just want to say it's quite probable I'm stupid.

~~~
dkersten
_Also, QML is a pretty awesome technology. I'm looking at how to use it to
speed up development._

Unless I'm doing basic forms, like you said, I've actually been using QML for
desktop apps (that is, I place a QDeclrativeView in my form and implement as
much of the UI as possible inside that, in QML). From what I've seen on the Qt
Labs blogs, this is what they are planning for desktop apps in Qt 5: QML for
the UI, C++ extensions and QWidgets available should you need them. (If you
don't need or want to embed the UI inside a QWidget, then you don't need
QDeclarativeView and use the QtQuick launcher instead - you can still
implement QML extensions in C++ and embed QWidgets and such)

So, yeah, QML is the way of the Qt future.

As for the limitations you mention:

 _1\. Implementing models are way too complicated._

So far, I haven't needed to do very much with models, so this hasn't got to me
yet, but they do look pretty complicated... so no arguments here.

 _2\. The widgets are very limited. For example, the table view requires hacks
to support clickable links. Not custom delegates or label but hacks. HTML/JS
widgets are way more flexible than Qt widgets. That says a lot._

I haven't noticed this really. Ok, yes, once you need lots of custom logic,
you do end up having to derive your own widgets so you can intercept events
and emit signals and so on, which can get complicated if, as is the case with
table views, the widget is some kind of container which interacts with some
kind of container items which you must also derive from. This definitely needs
to be streamlined somehow (I'm hoping that a lot of this can be eliminated
through QML), but it hasn't struck me as "limited".

As for the support stuff... I used to like QtConcurrent - but then I started
using TBB and have no need for it now. I like the Qt containers because I can
use foreach (of course, this is solved by C++0x), but I tend to use the C++
Standard containers or the TBB containers more often, unless the code only
interacts with Qt and very little custom or (non-Qt) library code.

~~~
cheez
It's limited because you can't end up with a completely proper solution. Then
you have to make a tradeoff between functionality, complexity and even
performance for something as simple as the example I gave above.

I think QML is an even better case for form-based UIs.

Completely declarative, everything is automatically bound, what's not to like?

