Quelle bibliothèque pour du GUI ?

C'est donc bien ce qui me semblait : signals et slots sont bien plus que de simples macros standards. L'utilisation le la bibliothèque Qt requiert l'utilisation d'un préprocesseur non-standard.
En conséquence, un compilateur C++ ne peut en aucun cas traiter un code Qt de façon native. Et il en sera de même pour un analyseur de code.

Quoi que…
Je réfléchis un peu. Puisque signals et slots sont #définies de façon standard dans le code, un préprocesseur standard n'y verra que du feu, et ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

#include <QObject>   class Counter : public QObject { Q_OBJECT   public: Counter() { m_value = 0; }   int value() const { return m_value; }   public slots: void setValue(int value);   signals: void valueChanged(int newValue);   private: int m_value; };

---

… deviendra cela :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

//inclusion de l'en-tête QObject   class Counter : public QObject { //remplacement de la macro Q_OBJECT par sa définition //(hors MOC, admettons que ce soit équivalent à du code vide, comme slots)   public: Counter() { m_value = 0; }   int value() const { return m_value; }   public: void setValue(int value);   protected: void valueChanged(int newValue);   private: int m_value; };

---

… ce qui est du code tout à fait standard, qui passera tout à fait l'analyse syntaxique. Le résultat de l'analyse sera donc correct… à condition que l'analyse sémantique n'aille pas trop loin (par exemple tracer précisément l'appel au callback) !

Bon bon bon… Qt remonte un peu dans mon estime ;)

Citation:

---

Merci pour le lieu commun, mais tout ce qui n'est pas Common Lisp le "réimplémente de manière bugguée et inefficace"...

---

C'était en effet une référence à cette fameuse citation, pour ceux qui n'avaient pas compris.
Citation qui est bien entendu de l'humour dans une certaine mesure, de nombreuses choses, en particulier celles qui n'utilisent pas de typage dynamique et ce genre-là, ne réimplémentent pas Common Lisp.
On pourrait néanmoins dire que GObject, par contre, en réimplémente vraiment pas mal.

Citation:

---

Envoyé par Florian Goo

C'est donc bien ce qui me semblait : signals et slots sont bien plus que de simples macros standards. L'utilisation le la bibliothèque Qt requiert l'utilisation d'un préprocesseur non-standard.
En conséquence, un compilateur C++ ne peut en aucun cas traiter un code Qt de façon native. Et il en sera de même pour un analyseur de code.

Quoi que…
Je réfléchis un peu. Puisque signals et slots sont #définies de façon standard dans le code, un préprocesseur standard n'y verra que du feu, et ceci :

… ce qui est du code tout à fait standard, qui passera tout à fait l'analyse syntaxique. Le résultat de l'analyse sera donc correct… à condition que l'analyse sémantique n'aille pas trop loin (par exemple tracer précisément l'appel au callback) !

Bon bon bon… Qt remonte un peu dans mon estime ;)

---

Mais comme les builders gèrent directement moc, ui et autres, on n'y voit que du feu ;)
Un analyseur de code ne verra pas grand chose, et il n'en a pas grand chose à faire, à vrai dire. Un connect ne fait que renseigner une table d'appel. Quand tu actives un signal, en fait tu exécutes un code généré par moc qui va chercher dans la table d'appel ce qu'il va faire. Rien de plus.

Citation:

---

Envoyé par Mongaulois

Je me demande aussi comment va évoluer Qt avec le prochaine standard aussi.

---

Comme je suis en auto formation JAVA... (no comment)
je regarde un peu QtJambi en parallèle.
Ils n'utilisent plus moc. Java fournie ce qu'il faut en meta donné.
Du coup les signal sont des class template et les slot sont appelé par leur signature :
http://doc.trolltech.com/qtjambi-4.4...sandslots.html

N'y aurait il pas possibilité de faire la même choses avec le prochain standard?

Le passage de Qt en java semble avoir su tirer partie de ce qui existe comme les thread, le méta donné,...

Vue la quantité de nouveauté du prochain standard, Qt subira peut être un mutation équivalente dans quelques années.

Je ne pense pas, car il n'y aura pas de réflexion dans le prochain standard, contrairement à ce qu'on trouve en Java.

La version java n'est pas non plus type-safe, ça marche avec des Object...

Citation:

---

Envoyé par loufoque

La version java n'est pas non plus type-safe, ça marche avec des Object...

---

c'est à dire?

Le défaut des signaux Qt (en C++/MOC donc) c'est qu'il ne sont pas type-safe.
Là, avec Java, on en aurait l'illusion à cause des génériques, sauf que les génériques de Java c'est un peu du vent, en fait ça marche avec le type de base (Object) et des tests à l'exécution. Donc c'est pas mieux.

À ma connaissance, ça n'est pas ce que signifie "type-safe".

type-safe signifie qui ne génère pas d'erreur à l'exécution à cause de mauvais types.

Il me semblait que ça voulait seulement dire que rien ne pouvait pointer vers un mauvais type, et que si erreur il y a, elle arrive *avant*. Java et C# (sans "unsafe") correspondent à cette définition de type-safe...

C'est pas plutôt type sound ça ?

Je ne sais pas, c'est la première fois que je vois ce terme...

Le gros problème des signal/slots QT, c'est qu'ils ne sont pas vérifiés à la compilation, et très sujets aux erreurs de frappe (problème qui existe moins quand on passe par le designer, c'est sûr). Pas sûr que ce soit un problème de type-safety à proprement parler. Mais ça fait des erreurs au runtime.

Je pense qu'il y aurait moyen de les réimplémenter, avec des templates, pour faire faire ce boulot de vérification par le compilateur, mais je n'ai jamais creusé plus loin pour l'instant...

Oui, ce moyen, c'est de ne plus utiliser MOC mais des templates...
Comme fait GTKmm, par exemple.

D'un autre côté,

Citation:

---

qmake -project && qmake && make

---

ce n'est pas dramatique par rapport à

Citation:

---

make

---

Tu n'utilises pas forcément un make tout bête.
Ça peut être plus ou moins difficile à intégrer en fonction du système de build utilisé.

Citation:

---

Envoyé par loufoque

Tu n'utilises pas forcément un make tout bête.
Ça peut être plus ou moins difficile à intégrer en fonction du système de build utilisé.

---

Tu exagères un peu. Les vrais outils actuels gèrent très bien Qt.