Discussion :

[dourouc05]

Outil adoré/détesté qu'est le moc, il est souvent reproché à Qt : pourquoi diable un tel framework a-t-il besoin d'un outil supplémentaire de précompilation ? Aucun autre n'en a besoin ! Les fonctionnalités fournies par cet outils sont aussi possibles sans (wxWidgets pour le système de signaux et de slots, CAMP pour l'introspection, etc.).

Sa présence conduit à l'existence d'autres outils : notamment, QMake pour l'appeler au bon moment lors de la compilation, des plug-ins spéciaux pour les EDI, etc.

Mais qu'en est-il réellement ?

Au début, il servait aussi à aplanir le terrain : les compilateurs avaient un respect très aléatoire de la norme, cet outil permettait l'égalisation du terrain, donc une utilisation plus vaste du framework. Ça, c'était Qt 1, en 1991. Qt 4 est sorti en 2005, disposant toujours de la bestiole. Pourtant, les compilateurs sont plus respectueux de la norme (notamment, en 2005 est sorti Visual Studio 2005, première version disponible partiellement disponible avec Visual Studio 2005 Express mais aussi troisième version à respecter la norme, la première étant Visual Studio 2002).

Reste la question de l'introspection : les compilateurs de l'époque n'étaient certainement pas aussi souples que les actuels. Admettons. Quid de CAMP, qui torture les compilateurs actuels mais fonctionne à merveille ? Il fonctionne à merveille sur VC7 et sur GCC 3.4.5, soit les versions les plus anciennes de ces deux compilateurs encore supportées par Qt. C'est donc possible.

À quoi sert-il donc ? A-t-il encore une utilité réelle ?

[yan]

wxWidgets pour le système de signaux et de slots

Ben c'est pas la même chose. C'est comme comparer les signal/slot de boost et de Qt, ce n'est pas la même chose. Le but n'est pas le même et il ne propose pas la même chose.

Pour l'introspection, c'est intimement liée et c'est un peu le même problème, c'est ne pas vraiment comparable. C'est l'objectif qui est différent.

De plus rien n'empêche d'utiliser d'autre signal/slot ou introspection plus adapté a nos besoin en parallèle de Qt.


Moc est là pour générer du code que l'on ne veut pas faire, simplifier l'écriture du code et pour le bon fonctionnement d'un ensemble de fonctionnalité interne. A peu prés tous les générateur de makefile le supporte sans problème. Les générateurs de code sont assez courant. Ce n'est pas aussi obscure.

[dourouc05]

Moc est là pour générer du code que l'on ne veut pas faire, simplifier l'écriture du code et pour le bon fonctionnement d'un ensemble de fonctionnalité interne. A peu prés tous les générateur de makefile le supporte sans problème. Les générateurs de code sont assez courant. Ce n'est pas aussi obscure.

Justement, n'y aurait-il pas d'autres manières de procéder que d'utiliser un outil propriétaire ? Les avantages de cet outil sont-ils suffisants pour qu'une autre solution ne puisse pas être envisagée ?*

[yan]

Justement, n'y aurait-il pas d'autres manières de procéder que d'utiliser un outil propriétaire ? Les avantages de cet outil sont-ils suffisants pour qu'une autre solution ne puisse pas être envisagée ?

Vue le fonctionnement de Qt pour moi non. Y as déjà eu un gros débat ici :
http://www.developpez.net/forums/d88...es-superobjet/
C'est sûr le super Object mais le moc découle du même problème.

Enlever le moc obligera le développeur à faire beaucoup de chose en plus. Comme de décrire tout les meta-data à la main ou faire attention sur les signaux (qui serais une classes pour le coup).

Travailler avec des template n'est pas forcement friendly. Sans compter qu'il y as des choses qui sont impossible à faire.


De plus, le fait d'avoir le moc permet d'éviter qu'un développeur ne fasse n'importe quoi . Surtout que plusieurs fonctionnalités importantes sont inter-dépendant entre eux ( signal/slot, metadata, eventloop, ...).

Je trouve qu'il explique bien leur points de vue ici :
http://qt.developpez.com/doc/4.6/templates/

[Amnell]

J'ajouterai à la suite du dernier lien de Yan celui-ci :

http://lists.trolltech.com/qt-intere...ad00000-0.html