How modern is C++ language used in Qt?

Question

I heard Qt API is written in pretty outdated C++ language. Is it true?
Are there any plans to make it use more modern C++ language? Are there any official information on this?

Are there any projects with the aim to wrap current Qt API constructs with more modern C++?

UPDATE
That's more to this question than templates and that's not the question only about the current state of affairs (that's why I tagged it with the future tag).

UPDATE
I'm especially concerned with Qt API as this is what users of this framework work with.
Using modern C++ language in API makes it more robust, flexible and easier to use.
What kind of C++ is used inside Qt is far less important to me.

Answer 1

Qt uses modern variants of the C++ language - currently C++98, and yes Templates are also used where it's appropritate. Qt has some support for STL. See e.g. http://qt-project.org/doc/qt-5.1/qtcore/containers.html - and convenience functions for e.g. std::string. It's all in the docs: http://qt-project.org/doc/qt-5.1/qtdoc/index.html ;) The question about templates vs moc is one we get so often we have added it to our documentation; http://qt-project.org/doc/qt-4.8/templates.html

Answer 2

Throughout the Qt 4.x lifetime, I doubt that it makes sense to rewrite parts of Qt to use e.g. "more modern" C++. This is because of the premise that all releases in the same major version of Qt should still be binary compatible. We also can not just obsolete or deprecate classes that the customers still use (although it is perfectly fine to introduce new stuff, even for a limited set of supported compilers).

If finally Qt 5 is almost out of the door, and the modern C++ constructs and features are finally available in the targeted supported platforms and compilers, and doing so will help C++ developers and customers to write better and more powerful code, then why not?

Answer 3

To directly answer your question, Qt's API is comprehensive. I'm pretty sure they'll come out with a QApp::ParkMyCar() function some time. They sometimes implement multiple ways of doing the same thing, with different positions on efficiency vs ease of use. Check out their (excellent) documentation. It is as comprehensive, and has saved my ass more than once.

From what I've seen of the Qt source code, the code is highly efficient.
Take a look at the features in the install configuration - you can turn on/off support for various features (including STL, threading and even the GUI). Further, when the Trolls made Qt 4 ground-up, they did not trade off features against code-jazz -they just delivered more of both. Given the quality of their programmers and their way of updating major versions, I don't think we need to worry about Qt (or parts) getting outdated.

Qt's target market (for desktops) is the MamaPapa company that makes Hello Kitty desktop alarm clocks, and wants to Code once and rest assured that it runs on all "sane" systems - Windows 98 and above, popular Linux distros and Mac OS X. This means pandering to the LCD of all the main compilers in each kind of system. If this means keeping template-wizardry in their code to a minimum, so be it.

Answer 4

Unlike Boost.Signals, Qt's implementation of signals/slots is thread-safe via the use of queued connections. On May 2nd, 2009, however, Boost.Signals2 was released and brought with it the much-desired thread-safety. From the developer point of view, Qt's implementation of signals/slots is much easier to use, mostly due to the fact that it does not use templates. For an in depth read of why Qt uses moc instead of templates for signals and slots, here's a page from their documentation.

For those wondering why Qt has its own set of container classes, I'm pretty sure that the main motivation was to offer implicit sharing. All of the container classes are implicitly shared, so whenever a QList is copied, only a pointer to the data is copied. See here for more information on shallow copying within Qt.

Answer 5

I really don't like the way Qt managed to implement its signals/slots mechanism. Their 'moc' precompiler really smells like a hack to me, and it doesn't even support standard C++.

I think it would be great if Qt could modernize itself to use at least the STL classes. What would be really awesome would be for Qt to use Boost whenever possible (especially Boost.Signals).

Answer 6

Qt is known not to use templates, one very useful modern c++ feature. But that does not mean that there is a need for a wrapper to Qt's API. Qt uses in-house precompilers to address the same issues. Some don't like this approach, but Qt's API is very simple and efficient, and i don't believe there is a real need to modernize it. In particular, signals&slots, a very impressive feature from Qt, can be achieved using templates (see boost.signals library), but the way Qt has implemented it is still much more efficient.

I'd say "don't worry and use Qt as is".

EDIT: Sorry i forgot about template containers provided with Qt. But still, Qt's API makes very little use of template classes. This does not mean that they don't use them inside Qt though or that their way of coding is obsolete.

Boost.Signals are probably more powerful than Qt signals/slots but, as far as i can tell, there is no arguing about which is simpler to use. One very convincing implementation of the KISS principle.

Answer 7

Qt sources contain the pattern "template <" 1280 times in src/corelib alone. I fail to see how this can be mistaken as "Qt is known not to use templates"

Answer 8

Qt is a library and needs to support a wide range of compilers. It still supports MSVC6, e.g. (I think Qt Software is phasing out support for this, though). This limits the more modern C++ features, Qt is able to use.

But this does not mean that you can't use them in your Qt program.

Answer 9

I, too, don't like the way Qt adds voodoo magic to C++. It uses so many macros that it awfully reminds me of C. At the moment, there is nothing to indicate that Qt would be kinder to C++ features in the future. I would really like to see it be more like C++ and not a language of its own (e.g. Why do we need std::vector<> and QVector<>? Or Qt signals, Boost.Signals and sigc++?)