There's nothing perfect under the sun. Qt is no exception, and it does have limitations: we can't use pixmaps in a thread other than GUI, we can't use QImage with 16-bit-per-channel image format, etc..

Which situations have forced you to spoil the design because of Qt's limitations?
What are the most hated quirks?
Which design decisions should one avoid while using Qt in his projects?

  • Can you say the Qt? If you expand it to "Q Toolkit", you can add a "the" in front of it, but is it correct/good-practice to say the Qt? Just curious.
    – Anto
    May 30 '11 at 18:35
  • @Anto: I suppose, the is bound to corners here, not Qt, but it's only my intuitive feel, since I'm Russian :)
    – vines
    May 30 '11 at 19:41
  • One possible dangerous curve is that the project may be in financial trouble. Nokia recently signed an agreement with Microsoft (to use Win7 on their phones) that puts Qt's future on shaky ground. Jun 6 '11 at 0:24
  • i am very interested in knowing this answer because i am a noob to C++ visual programming :D
    – Shaheer
    Jun 13 '11 at 17:10
  • @Vines: How about "What are the dangerous corners of QT?"?
    – Chris
    Jun 15 '11 at 17:01

Ironically, I'd say Qt's power is also one of the drawbacks. There are so many powerful constructions and extensions, code you write in Qt easily becomes highly entrenched in the "Qt way". Trying to extract functionality into another language not only means a re-write, you need to know a lot of Qt-specific technology.

Qt's breadth means that hiring programmers means either committing to someone with Qt experience, or training for that expertise. Getting a contractor in and up to speed is harder than vanilla C++.

When Qt changed from 3.x to 4.x, our team required almost 9 months to do the port, during which time little new functionality was added. You hope to make up that major upgrade cost in increased development efficiency the rest of the time. (Note, I've omitted the advantages of Qt, of which there are also many)

  • 2
    The Qt3 to Qt4 port was hard to most people I know. This QML and similar things that have been introduced in the newer versions makes me worried, since it may means once again a complicated port coming.
    – Vitor Py
    Jun 22 '11 at 12:30

Qt does not use the standard C++ library, but has its own QString, QVector, QMap, ...

This means you have to make an important design decision: what parts of the application will use QString and which parts will use std::string?

Using std::string in some parts and QString in other parts, means you'll have to convert between QString and std::string on the bounderies.

To avoid that overhead, one could decide to use QString all over your application. But that makes it much harder to use 3rd party libraries that are not based on Qt, e.g. boost.

(Note that the same applies to std::map vs QMap, std::vector vs QVector, and so on)

Deciding which parts use Qt's types and which parts use the STL is a major design decision, with major implications. And only because Qt refuses to use the standard C++ libary.

IMHO, that decision could go either way, depending on the project. So I cannot answer your question which one to avoid.

  • 1
    I agree, but I would go out on the edge and say that the QString (etc etc) is also one of the strengths since it is so nice to work with them.
    – Johan
    Jul 14 '11 at 11:48
  • 1
    Also, it isn't all that hard to use a library that doesn't use QString. There is a simple method to convert a QString to a std::string and vice versa. Not much to it.
    – user7007
    Jul 14 '11 at 11:51
  • @Glenn Nelson: Yes, nowadays there are conversion functions for QString; very useful and convenient! But especially for QVector and QMap there will be overhead in converting (and simple solutions won't work for e.g. QVector<QString>); That overhead should be considered during design to avoid performance problems down the line.
    – Sjoerd
    Jul 15 '11 at 16:18

This doesn't directly answer the question, but I think it's worth mentioning: perhaps the most 'dangerous' aspect of Qt is that Nokia has gotten into bed with MSoft...

  • 2
    But they abandoned Qt to do it. Jul 14 '11 at 2:40
  • 1
    For completeness sake - The commercial part of Qt is now owned by Digia, whereas Qt has moved to a system of "open governance" where others can easily contribute. There is also the KDE Free Qt foundation which protects Qt from going closed source. Mar 26 '14 at 14:38

Recently I found out that a QChar, despite its name, does not actually correspond to one character but to a UTF-16 code unit. Thus, when you want to scan an arbitrary Unicode text character by character, you have to add algorithms for dealing with high and low surrogates, combining characters and the like.

Not the answer you're looking for? Browse other questions tagged or ask your own question.