Laurent a écrit 9 commentaires

Tout d'abord, QObject impose des restrictions purement techniques :
- en cas d'héritage multiple, QObject doit être la première base
- on ne peut pas hériter de plusieurs classes dérivant de QObject
- un objet dérivé de QObject n'est pas copiable

Ensuite, ce système est intrusif. Il faut en effet taper directement dans la déclaration de la classe pour modifier ses meta-informations.
Conséquence directe : on ne peut pas appliquer le système sur des classes figées et non prévues pour fonctionner avec Qt (par exemple je ne peux pas créer une meta-classe Qt pour la classe Toto de la bibliothèque SuperLib que je viens d'installer -- dommage).

Dans une moindre mesure, le côté intrusif est également pénalisant au niveau des dépendances entre les fichiers (temps de compilation accrus) et de la maintenance (le code relatif aux meta-informations est imbriqué dans la déclaration de la classe et mélangé au reste).

Enfin, on ne pourrait pas non plus utiliser les meta-informations uniquement de manière interne, avec un tel système on est obligé d'exposer les meta-informations à toute personne extérieure qui utilise la classe.

De manière générale, on apprend toujours que découpler les fonctionnalités orthogonales est meilleur que de tout imbriquer ensemble.

Avec Qt on est obligé d'ajouter du code spécifique pour "piloter" le précompilateur, donc où est l'intérêt de celui-ci ? Autant écrire directement le binding, c'est un peu plus verbeux mais au moins on évite l'utilisation du précompilateur, et on atteint un degré de flexibilité bien supérieur (et ne me dis pas que le binding entre membres C++ et proriétés/slots est flexible avec Qt).

Ces informations sont intrusives car elles se trouvent à l'intérieur de la définition de la classe. Qu'elles soient bien placé ou non n'y change rien : ta classe sera forcément fortement couplée au système de meta-objet et dépendante de celui-ci. Or je ne t'apprendrai rien en te disant que le découplage des fonctionnalités orthogonales est une bonne chose en C++.
Par exemple, limitation très simple : avec un tel système (intrusif) il est impossible de binder une classe qui n'a pas été prévue dès le départ pour cette utilisation (et on ne bosse pas toujours avec des classes qu'on a écrites soi-même).

En ce qui concerne les précompilateurs, on ne s'est pas encore penchés sur le problème, mais il y a des projets connus qui devraient répondre à ces attentes. C'est un projet à creuser un peu plus.

CAMP n'est pas incompatible avec l'utilisation d'un précompilateur. Les gens peuvent en utiliser un s'ils le veulent, pour générer les déclarations de meta-classes. Donc je trouve que c'est au contraire un avantage que CAMP n'impose pas directement l'utilisation d'un précompilateur, c'est à l'utilisateur de choisir ce qu'il préfère.

En plus, utiliser un précompilateur implique que l'utilisateur n'a aucun degré de personnalisation sur les infos qui sont exportées :
- choisir ce qui est exporté et ce qui ne l'est pas
- ajouter des informations non présentes dans le code C++ (tags, visibilité, informations d'ownership, ajouter de l'aide, ...)
- changer le nom des symboles exportés
- ...
Pour pallier à ça il faudrait ajouter des informations spécifiques dans le code (intrusives !), et dans ce cas on perd tout l'intérêt du précompilateur, autant écrire le binding directement.

Ceci-dit, idéalement nous pourrions choisir un précompilateur parmi les outils libres existant, et l'adapter pour proposer directement aux utilisateurs notre propre précompilateur pour CAMP. Je pense que ce serait un très bon ajout pour CAMP.

Salut

Soyons clairs : CAMP fournit un service d'abstraction haut niveau pour programmes plus ou moins conséquents, pas un truc dont le but est d'être embarqué sur des systèmes avec 32 Ko de mémoire vive. Si tu cherches quelque chose qui économise 100 octets ou qui ne fragmente pas la mémoire, alors clairement CAMP ne t'intéressera pas, ce n'est pas la voie que l'on poursuit.

En ce qui concerne les avantages, utiliser un préprocesseur n'est pas un luxe que l'on peut toujours se permettre car cela complexifie la chaîne de compilation. Par exemple, avec Visual Studio sans le plugin d'intégration Qt (qui n'est pas disponible librement), c'est quasiment impossible de développer, les règles d'invocation des différents outils de précompilation de Qt sont bien trop laborieuses à écrire.

L'avantage de ne pas hériter de QObject n'est bien sûr pas d'économiser 100 octets, mais de se débarasser d'une dépendance sur les classes et de rendre le système non-intrusif. C'est un gage de maintenabilité et de d'adaptabilité très important, et ça évite les petites surprises du genre "on ne peut pas hériter de 2 bases QObject". En clair, avec CAMP tu peux binder std::string ; pas avec Qt.

Quant à l'enregistrement manuel des metaclasses, rien n'empêche d'utiliser un précompilateur du genre gccxml ou open-c++ (désolé si les noms sont approximatifs) pour générer le code d'enregistrement. L'important est que l'on n'impose pas d'outil externe à l'utilisateur, c'est lui qui choisit.

Nous sommes soucieux des performances, de sorte que CAMP ne soit pas un frein quelque soit l'utilisation que l'on en fait ; concrètement il faut qu'on puisse utiliser CAMP pour binder des classes en Python ou en Lua et garder le maximum de performances que ces langages fournissent.

Enfin, oui nous comptons bien entendu préserver une compatibilité binaire et source. A partir de la version 1.0, les choses seront faites dans les règles.

Tout à fait, mais de toute façon là je parlais de GICS ; CAMP quant à lui utilise tout un tas de modules de metaprogrammation que l'on ne retrouve que dans boost.

Comme je l'ai dit on a besoin de boost principalement pour le système de meta-propriétés, qui constitue les fondations de tout le framework (un peu comme les propriétés Qt constituent la base de tout ce qui est à base de QObject). On ne fait pas que du SVG et du CSS, ça ce n'est que la partie personnalisation visuelle du framework.

On a également besoin de boost pour les classes utilitaires classiques : pointeurs intelligents, conteneurs, ... Se passer de boost de nos jours est bien souvent une erreur, en tout cas un pas en arrière et une perte de temps, d'autant plus que bon nombre de ces classes vont figurer dans le prochain standard C++.

Comme indiqué plus haut, le problème de consommation CPU a été corrigé récemment.

Pour la fenêtre qui clignote, c'est sous quel OS ?
Qt sous Mac OS X a des problèmes avec ce genre d'effet, qui seront d'ailleurs peut-être reglés avec la version 4.6.
Sous Linux aussi on a quelques clignotements, mais là encore on suspecte le serveur X ou le WM plutôt que directement le code de la démo.
Sous Windows aucun souci normalement.

CAMP est la base du système de meta-propriétés. Alors évidemment on aurait aimé utiliser celui de Qt, mais lors de l'étude préliminaire on s'est vite rendus compte que ce dernier serait insuffisant, trop peu flexible (voir ma réponse à la question «différence entre CAMP et QMetaObject»).
Quant à boost, c'est le minimum syndical pour des bibliothèques comme CAMP qui torturent le compilateur dans tous les sens.

En ce qui concerne les widgets SVG présentés sur le site de Qt, c'est plus une démo qu'un outil. Il n'y a rien de vraiment intéressant autant au niveau API que technique, ils ont développé ça surtout pour montrer que l'on pouvait faire des trucs jolis avec Qt, du SVG et des feuilles de style. Mais il n'y a rien de vraiment réutilisable.
GICS au contraire, fournit non seulement un ensemble d'instruments, mais surtout un framework complet et générique pour en développer des nouveaux très facilement.

CAMP est un système beaucoup plus générique et poussé que les propriétés de Qt. Le système de QMetaObjects est relativement centré autour d'une utilisation bien précise et donc peu flexible.

Quelques avantages de CAMP pêle-mêle :
- non-intrusif pour la classe bindée
- possibilité de binder des classes externes
- pas besoin d'appartenir à une hiérarchie de QObject
- pas besoin du précompilateur MOC
- possibilité d'héritage multiple
- on peut binder tout type de membre sans limitation, pas seulement des couples de getter/setter au prototype figé
- les propriétés peuvent avoir des attributs et des tags dynamiques, qui peuvent servir à personnaliser et étendre le système au-delà de ce qu'il prévoit initialement
- ...