Quelle bibliothèque pour du GUI ?

**Florian Goo** · 15/01/2009, 16h25

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

**loufoque** · 15/01/2009, 16h33

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.

**Matthieu Brucher** · 15/01/2009, 16h56

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.

**yan** · 16/01/2009, 12h58

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.

**Alp** · 16/01/2009, 13h29

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

**loufoque** · 16/01/2009, 17h17

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

**yan** · 16/01/2009, 18h23

Envoyé par loufoque

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

c'est à dire?

**loufoque** · 16/01/2009, 21h49

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.

**Médinoc** · 17/01/2009, 15h45

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

**loufoque** · 17/01/2009, 18h38

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

**Médinoc** · 17/01/2009, 20h19

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...

**loufoque** · 17/01/2009, 21h27

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

**Médinoc** · 17/01/2009, 21h32

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

**white_tentacle** · 19/01/2009, 09h18

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...