Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

closed as not constructive by ChrisF Sep 20 '11 at 11:09

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

    
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. –  Peter Rowell 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

4 Answers 4

up vote 12 down vote accepted

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)

share|improve this answer
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 Jun 22 '11 at 12:30

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...

share|improve this answer
2  
But they abandoned Qt to do it. –  Martin Beckett Jul 14 '11 at 2:40
    
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. –  Vishesh Handa Mar 26 at 14:38

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.

share|improve this answer
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. –  Glenn Nelson 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

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.

share|improve this answer

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