Discussion :

[guillaume07]

Hi,

A l'époque de Qt 1.x. les templates n'étaient pas assez homogène.
Aujourd'hui visiblement ça n'est plus le cas, serait-il alors possible de se passer du système de moc pour le remplacer par un système à base de métaprogrammation via les templates ?

Tout ceci dans le but de rester ultra standard.

Merci

[dourouc05]

Salut,

Le moc ne sert plus actuellement qu'à uniformiser les compilateurs sur certains points : il sert aussi et surtout à gérer le système de signaux et de slots, l'introspection... Si tu utilises ces spécificités de Qt, tu dois utiliser le moc. Sinon, tu n'y es pas obligé : tu peux le laisser tomber et n'utiliser que les classes de Qt qui ne les utilisent pas.

[guillaume07]

Salut,

Le moc ne sert plus actuellement qu'à uniformiser les compilateurs sur certains points : il sert aussi et surtout à gérer le système de signaux et de slots, l'introspection... Si tu utilises ces spécificités de Qt, tu dois utiliser le moc. Sinon, tu n'y es pas obligé : tu peux le laisser tomber et n'utiliser que les classes de Qt qui ne les utilisent pas.

exact mais sans les signaux, ça me paraît difficile d'avoir une GUI fonctionelle

[yan]

http://qt.developpez.com/doc/4.6-snapshot/templates/

[guillaume07]

en faite le moc ça revient à quoi ? a utiliser le préprocesseur plutôt que les templates ?

[yan]

en faite le moc ça revient à quoi ? a utiliser le préprocesseur plutôt que les templates ?

A générer du code que tu n'aimerais pas faire toit même.
Si tu regarde la définition de Q_OBJECT, c'est un ensemble de fonction utilisé pour les meta données.
Le moc, va implémenter ces fonctions.

[guillaume07]

ok je vois.

Une chose embêtante cela dit est l'impossibilité d'avoir une classe template dès lors qu'elle contient des signaux/slots ou autres macro prédéfinies dans les Header de QT.

Avec une solution à base de template, on ne pourrait pas avoir un système d'introspection complet (utilisant les Q_Property par exepmple), on ne pourrait pas non plus avoir un système de translation pour gérer les différentes langues, on aurait une syntaxe peut être plus lourde, mais en contre partie on aurait un code plus rapide, et pas de limitation sur l'utilisation de paramètres templates avec des classes encapsulant un système de signaux/slots

[Alp]

Et tu te frapperais la tête contre le mur pendant des jours pour compiler ton code avec un compilo pour mobile ou autre qui ne suit pas assez la norme. Qt mise sur la portabilité maximale. Et avec leur système de metacall le temps d'exécution est loin d'être désastreux. Je sais que l'on peut métaprogrammer ça (j'avais écrit un tel système, à échelle réduite, pour un projet), mais disons que ça sort des "guidelines" de Qt. Ils ne sont pas trop trop dans l'ère du modern C++.

[guillaume07]

certes du point de vue mobilité, ça suffit à expliquer leur choix, mais peut être serait il top d'avoir une version de QT sous forme de template dans le cas ou le compilo respecte le standard C++.

Mais visiblement ça n'est pas leur philosophie

[Alp]

Bah maintenir deux systèmes de meta-objets, avec une certaine compatibilité entre les deux (histoire que la migration pour des projets existants soit possible), c'est quand même énormément de temps, de personnes et d'argent du coup, pour très très peu de d'avantages.

[guillaume07]

on est d'accord

[guillaume07]

Et tu te frapperais la tête contre le mur pendant des jours pour compiler ton code avec un compilo pour mobile ou autre qui ne suit pas assez la norme. Qt mise sur la portabilité maximale. Et avec leur système de metacall le temps d'exécution est loin d'être désastreux. Je sais que l'on peut métaprogrammer ça (j'avais écrit un tel système, à échelle réduite, pour un projet), mais disons que ça sort des "guidelines" de Qt. Ils ne sont pas trop trop dans l'ère du modern C++.

d'un autre côté en 2009 les principaux os cible ont un compilo qui supporte bien les templates , donc aujourd'hui cet arguement est plus trop valable

[Alp]

Oui, biensûr, le seul soucis étant qu'avoir cette hétérogénéité -- et des clients qui utilisent des compilos pourris sans pouvoir en changer -- ça mettrait un bazar pas possible pour eux. Ils ne gagneraient vraiment pas beaucoup à faire ça maintenant.

Après, je ne serais pas contre mais bon je comprends leur décision.

[yan]

No Limits

Because we had the moc for signals and slots, we could add other useful things to it that could not be done with templates. Among these are scoped translations via a generated tr() function, and an advanced property system with introspection and extended runtime type information. The property system alone is a great advantage: a powerful and generic user interface design tool like Qt Designer would be a lot harder to write - if not impossible - without a powerful and introspective property system. But it does not end here. We also provide a dynamic qobject_cast<T>() mechanism that does not rely on the system's RTTI and thus does not share its limitations. We use it to safely query interfaces from dynamically loaded components. Another application domain are dynamic meta objects. We can e.g. take ActiveX components and at runtime create a meta object around it. Or we can export Qt components as ActiveX components by exporting its meta object. You cannot do either of these things with templates.

C++ with the moc essentially gives us the flexibility of Objective-C or of a Java Runtime Environment, while maintaining C++'s unique performance and scalability advantages. It is what makes Qt the flexible and comfortable tool we have today.

[guillaume07]

ça reste des utilisations marginales

- pour le tr, un xml peut faire l'affaire
- pour le designer, je crois que beaucoup font leur GUI à la mano
- pour les meta object, c'est pas tous les jours qu'on a besoin de créer un object au runtime autour d'un active X


Enfin, je ne dis pas, peut être que leur framework est mieux avec le moc, mais je sais pas ça me laisse un goût amer...