The problems of Qt, not just 4

• qrand() requires generating random bits and seeding it via qsrand() for it to return random numbers
• operators plus for string concation are inefficient and require binary incompatible solution (QStringBuilder) to produce "faster" results (which also make a data relocation, just compare the string builder templates with the plus operators) while a simpler solution is possible via unintialised but with right size container to which the result is copied or using static pointer to concated strings
• pixmap caching of non-generated pixmaps relying on generated keys with race condition
• binary compatibility workarounds
• pretty much everything from the core component is provided or planned to be by the standard C++ library with C++11 and newer
• up-casting of private data pointers via reinterpret_cast<T> and static_cast<T> which increases build times and other non-sense (build with -Wuseless-cast and observe)
• many build options are not tested properly leading to build failures and bloat in certain cases
• what the toolkit recommends it does not take into account, e.g. Q_DECLARE_INTERFACE is not used outside namespace in the toolkit itself, build failures with QT_NO_DEPRECATED, QT_NO_CAST_FROM_BYTEARRAY, etc.
• enumerators and definitons clashes partitially solved via #undef, #error, renaming and so on
• exposes its unstable internals
• installation is broken by default, somewhat fixed by each distributions
• database drivers are known to be broken and with limited functionality, workarounds even in tests
• const violations leading to use of const_cast<T> and performance penalty due to copy of data
• qmake requires mkspecs for each toolchain variant meaning porting to new variants will lack support for it in versions prior that which it is introduced in
• does not report warning and error conditions to GUI users (e.g. QThread start failures) which may lead to unexpected results in applications
• functionality provided by the host (e.g. standard functions/struct members availability) are assumed to be present for certain types of hosts making feature platform and architecture ports harder than they should be and possibly not making use of features implemented by the platforms later on
• uses global state data, such as caches and codec for C-strings, which may have side-effects and one would have to take into account when troubleshooting issues
• API pitfails due to underlaying use of QIODevice and derived classes which require seek for read-write (QIODevice::ReadWrite) operations
• template classes stored in non-template one (e.g. QMap<T> in QVariant) making bindings for other languages unnecessarily complicated
• no means to filter messages from messages handler installed via qInstallMsgHandler (internal toolkit related, other library related, etc.)
• QKeySequence is absolute mess, it should represent actual key sequence (e.g. QKeySequence(Qt::Key_Control, Qt::Key_Shift, Qt::Key_H)) instead of mixed bits of modifiers and keys.QShortcut should represent primary and secondary shortcuts (e.g. QShortcut(const QKeySequence &primary, const QKeySequence &secondary)). Example of misuse of enums: https:/fluxer/katie/blob/69d2ac47bf1afe706b832d29cf50f0570351c225/src/gui/dialogs/qfiledialog.cpp#L2293
• QString substring getters (e.g. QString::mid()) can chop off low or high surrogates
• promoted behaviour like implicit QLibrary unloading on application exit
• ... many more