Why The QT Framework Sucks

[Asphyxia]

I'm going to start off by quoting an awesome person by the name of Adam Hawes, a stranger to me on StackExchange.

I really like Qt, but it's a bit heavyweight for a lot of applications. Sometimes you just don't need that level of complexity. Sometimes you just need something simple without all the overhead of Qt. Not every application needs to be event driven and C++ provides a reasonable set of templates. Boost provides another very good set and includes a lot of the low-level functionality (file, socket, managed pointers, etc) that QT does.

Other applications have licensing requirements that don't play nice with GPL, LGPL or Qt's commercial license. The GPL is inappropriate for commercial software. The LGPL is inappropriate for statically linked software and the commercial license costs money - something that many are unwilling to pay.

Some have security or stability considerations that don't allow complex libraries like Qt.

You need to run moc to pre-process your sources. That's not a huge issue, but it can be daunting for the new user. A lot of programmers think you need to use qmake with Qt, but that's a misnomer. It is possible to plug Qt into other build systems pretty easily.

Some targets are very memory or CPU constrained.

There some platform-specific gotchas in it. Most of those gotchas are undocumented. Build a sufficiently large application and you will run into them and wonder what's going on (disclaimer, the last time I used Qt in anger was over 18 months ago, so it may have improved).

It's C++ only. Other language bindings exist, but they tend to hide or poorly expose a lot of the functionality that you'd want Qt for.

There's a lot of reasons to not use Qt, that's why there are alternatives. If all you have is a hammer then every problem will look like a nail.

I plan on making a YouTube video explaining why the QT Framework is not the one-size-fits-all solution for software development. You should never trade security for speed. You would not choose to go 200 mph/321.869 kph (exaggeratedly high number) in a car if it required your safety equipment to be turned off, especially knowing there are people shooting automatic guns at your tires. You should not make software quickly at the cost of your software users having security risks.

There are different options for everything. QT is not the bug-free and security-smart choice --- clearly.
http://www.linux-magazine.com/Online/News/Trolltech-Removes-Qt-Vulnerability
http://lists.qt-project.org/pipermail/announce/2015-April/000067.html
It is possible the latter could be used to perform remote code execution.
http://www.cvedetails.com/vulnerability-list/vendor_id-12593/product_id-24410/Digia-QT.html
Buffer overflow in the TIFF reader in gui/image/qtiffhandler.cpp in Qt 4.7.4 allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via the TIFFTAG_SAMPLESPERPIXEL tag in a greyscale TIFF image with multiple samples per pixel.
Heap-based buffer overflow in the Lookup_MarkMarkPos function in the HarfBuzz module (harfbuzz-gpos.c), as used by Qt before 4.7.4 and Pango, allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a crafted font file.

So, there you have it. Next time you think about selecting a framework, consider security a real thing. It is a real thing and it is important --- not magic, simply intelligence. Security is a careful science with a mixture of artistic characteristics. Be scientific when making development decisions about security though, not creative.