Quelques mythes
moc ne réécrit pas le code qui lui est passé, il ne le réécrit pas : il l’analyse et génère de nouveaux fichiers C++, qui sont ensuite compilés de manière totalement indépendante. Sans l’outil, pour utiliser l’architecture actuelle de Qt, il serait nécessaire d’écrire de grandes quantités de code pour les tables d’introspection et d’autres détails nécessaires pour le fonctionnement des signaux et slots.
Il se concentre sur une série de macros définies par Qt pour générer son code : Qt ne définit pas de « nouveaux mots clés » C++. Pour définir une classe héritant de QObject, la macro Q_OBJECT évite au programmeur d’écrire une série de déclarations de fonctions (dont le code est généré par moc). Les signaux sont définis dans un bloc signals:, qui n’est autre qu’une macro qui correspond à public:. Bon nombre d’autres macros utilisées par le moc ne génèrent aucun code. Globalement, le code Qt reste du code C++, ce qui fait que tous les outils C++ traditionnels restent utilisables.
Son utilisation ne complique pas la compilation ou le débogage : la plupart des systèmes de compilation traitent de manière native moc ; de toute façon, il s’agit simplement d’une commande supplémentaire à appliquer sur les fichiers d’en-tête. En cas d’erreur à la compilation (ce qui est très rare), le code généré est plus facile à comprendre que l’embrouillamini généré par les templates C++.
Certains ont tenté de supprimer moc, comme CopperSpice, en promettant notamment une amélioration de performance. Cependant, cette affirmation n’est pas sous-tendue par des chiffres : le graphique ci-dessous indique que la taille des exécutables générés est bien plus grande avec CopperSpice (sans moc) que Qt (4 ou 5, avec moc). De manière générale, le code généré par moc est très efficace : il est entièrement statique et évite toute allocation dynamique de mémoire, ses données sont stockées dans les segments de données en lecture seule — là où CopperSpice génère ces mêmes données à l’exécution.
Finalement, moc évolue : depuis Qt 5, il gère complètement les macros, ce qui permet de les utiliser pour définir des signaux, des slots, des classes de base, etc. Q_PROPERTY n’autorisait pas, jusqu’il y a peu, les virgules dans ses arguments (par exemple, en lui passant un QMap), ce qui a été réglé en un rien de temps.
Des fonctionnalités absentes
Finalement, la plus grande critique de moc est probablement qu’il ne gère pas les classes avec des templates, des classes imbriquées ou l’héritage multiple. Cependant, si elles ne sont pas implémentées, c’est principalement parce qu’elles ne sont pas jugées importantes. Par exemple, une implémentation des templates a été rejetée il y a trois ans ; moc-ng, une implémentation de moc sous la forme d’extension du compilateur Clang, gère sans problème les templates et les classes imbriquées. L’héritage multiple reste possible à condition que QObject soit la première classe de base — ce qui permet bon nombre d’optimisations, de telle sorte que qobject_cast est bien plus rapide que la version standard dynamic_cast.
Et donc ?
moc n’est pas vraiment un problème, ses plus grands pourfendeurs sont généralement ceux qui le connaissent le moins. L’API et notamment le système de métaobjets et la connexion entre signaux et slots sont à la base du succès de Qt. Les avantages des autres solutions sont loin d’être clairs et moc n’est pas une limitation pour les développeurs.
Source : Moc myths debunked.
Ce contenu a été publié dans Qt par dourouc05.
Envoyé par dourouc05
