-
With Signal and Slot connections, Slot parameters could not be a Method Pointer or a Function Pointer as parsing did not work properly
-
QObject::findChildren method utilized a C type union in a manner which can produce undefined behavior and is compiler dependent
-
During QObject instantiation, multiple objects were created which led to increased overhead. Merging these classes has resulted in less overhead and better use of memory
-
Moc does not support nested classes
-
Methods belonging to classes like QObject and QMetaObject, which were not documented in the published API, were not clearly marked as internal and often declared as public
-
Prior to VC++ 7 (released in 2002), Microsoft did not support the ability to implement a Class Method as a template. Classes like QMetaMethod benefit from having template methods. QMetaMethod::invoke() has been redesigned and simplified
-
Q_PROPERTY only allowed specific data types. For example, moc required QMap to be in the form of QMap<QString, QVariant>
-
Moc can not support a templated class inheriting from QObject
-
In Qt 4 all connections were made using string comparisons which can result in slower run time execution
-
Moc did not allow for compile time checking of Signal and Slot arguments
-
Header files from libraries such as Boost, must often be hidden from moc by using include guards (#ifndef Q_MOC_RUN)
-
During a cross compile of Qt (compiling on one OS for another OS) moc is only built for the host operating system
-
Third party build systems do not support moc without significant changes to the project files
-
Poor error reporting when a moc file is out of sync, fails to be generated, or is missing from the project
No version of Qt can be built without moc so there is an intense and very error prone bootstrap process
Building Qt from source requires their supplied Configure program to run syncqt
. This in turn builds a special bootstrap version of QtCore which is used to build QMake. Moc, UIC, and RCC all link with the bootstrapped version of QtCore.
A #define is then flipped to build the real non-bootstrap version of QtCore. This processing means switching to a different build system is not possible without a great deal of work and knowledge of the QtCore library.