[Debat] C++ et IHM

**Matthieu Brucher** · 22/08/2007, 14h16

Je vais faire mon chieur, mais une IHM en C#, non merci, je préfère la faire... en Python, beaucoup plus rapide à mettre en place.

Ca me rappelle quand Alp et moi sommes passe sur un autre forum pour dire que en C++ les templates c'etait le bien contre quelqu un qui disait que ca ne servait a rien puisqu'on peut tout resoudre avec de la POO. Mon argument c'est que CERTES ca marche mais que certains outils sont encore mieux adaptes (et ca vaut mieux puisque ils ont ete fait pour)

Tout à fait d'accord, d'autant que les template sont super utiles pour la POO.

screetch · 22/08/2007, 14h17

Envoyé par Miles

Je vais faire mon chieur, mais une IHM en C#, non merci, je préfère la faire... en Python, beaucoup plus rapide à mettre en place.

Oui c'est vrai, je n'ai pas essaye d'etre exhaustif. Le Python a aussi le RTTI tres pratique pour les IHM et une flexibilité runtime que le C++ n'a pas.

**NiamorH** · 22/08/2007, 14h22

Je suis assez d'accord avec rod pour dire qu'utiliser le framework .Net pour faire une IHM standard, fonctionnelle, mais peu personnalisée (d'un point de vue contrôles avec des nouvelles images, animations) reste le best. Tout est là pour qu'en trois secondes on ait quelque chose qui marche et solide.

Maintenant dès qu'on cherche à sortir un peu des sentiers battus, ben on s'en mords les dents.

Qt, même si j'ai peu pratiqué, je ne suis pas fan. Ok il apporte la portabilité, mais je ne le trouve pas très beau, il me semble qu'il manque des fonctions élémentaire de docking, anchoring des composants au profit de layouts un peu déroutants, l'installation et l'utilisation en elle même n'est pas triviale, etc.
Je ne suis allé assez loin pour savoir si la personalisation d'applis est plus simple.
Sans être une critique j'aimerais aussi comprendre pourquoi ils ont choisi un système signal slot interne, alors que des solutions C++ pur étaient possibles, mais je pense que les signaux ne sont pas la seule raison pour laquelle ils utilisent MOC si ?
Je pense que j'aurais également mieux adhéré si ils s'étaient limités à une IHM plutôt que vouloir créer un framework à tout faire.

**Jean-Marc.Bourguet** · 22/08/2007, 14h25

Envoyé par NiamorH

Sans être une critique j'aimerais aussi comprendre pourquoi ils ont choisi un système signal slot interne, alors que des solutions C++ pur étaient possibles

A l'epoque ou QT a ete concu?

**Matthieu Brucher** · 22/08/2007, 14h30

En 3 secondes, on a aussi qqch avec Qt qui marche (vive le designer).

Plus sérieusement, Qt est beau si on considère que les plateformes natives ont de belles fenêtres puisqu'il utilise les styles par défaut, y compris le dernier .Net dans les QSolutions, et on peut aussi créer son propore style, c'est tout de même appréciable !

Le mécanisme de signaux et slots est très efficace car il permet de communiquer entre threads ou dans le même thread de manière transparente en utilisant le meilleur mécanisme. Une pompe à message effectue la même opération, sauf que là, on a directement accès aux outils pour outre passer la pompe. Il n'y aucun outil en C++ pur qui permet de faire ce que Qt propose, Boost.Signals s'en approche, mais il n'est pas thread safe, donc il y a de la marge !

Enfin, ils ne se limitent pas à une IHM parce que Qt, c'est aussi KDE, c'est surtout DBus sous Linux - et oui, ils sont à l'origine de ce mécanisme qui existe depuis très longtemps sous Windows pour la communication entre applications -, c'est aussi un pont vers Qtopia qui est une solution tout en un pour les solutions portables (PDA, téléphones, ...) et le code Qt est compatible à 100% avec le code Qtopia, pratique pour le débuggage, non ? Et pourquoi le réseau ? C'est super utile, wxWidgets propose aussi sa propre couche, comme Boost maintenant. Idem pour accéder à des bases de données, des fichiers XML, ...

**yan** · 22/08/2007, 14h32

Envoyé par NiamorH

Je pense que j'aurais également mieux adhéré si ils s'étaient limités à une IHM plutôt que vouloir créer un framework à tout faire.

Tu peut voir tout cette ensemble comme un framework puissant pour faire des IHM personnalisé simplement (faut bien comprend l'héritage).
Mais pour cela faut bien concevoir ces class pour ne pas mélanger le code avec l'IHM et rester en mode vue - contrôleur.
Je suis d'accord qu'il n'aurai pas du tout mélanger : conteneur; thread, d-bus, IHM ...

**koala01** · 22/08/2007, 14h41

Envoyé par screetch

non! ^^
- le C++ ne permet pas l'introspection (le RTTI) qui est un ajout de C#

Le C++ n'a pas l'introspection, mais il ne faut pas confondre cela avec le RTTI (Run Type Type Information), qui est géré en natif en C++ et qui n'est pas une "émulation du C#"... Merci de ne pas confondre

Envoyé par NiamorH

Je suis assez d'accord avec rod pour dire qu'utiliser le framework .Net pour faire une IHM standard, fonctionnelle, mais peu personnalisée (d'un point de vue contrôles avec des nouvelles images, animations) reste le best. Tout est là pour qu'en trois secondes on ait quelque chose qui marche et solide.

Maintenant dès qu'on cherche à sortir un peu des sentiers battus, ben on s'en mords les dents.

Heuu... Ce serait pas plutot les doigts

Envoyé par NiamorH

Qt, même si j'ai peu pratiqué, je ne suis pas fan. Ok il apporte la portabilité, mais je ne le trouve pas très beau, il me semble qu'il manque des fonctions élémentaire de docking, anchoring des composants au profit de layouts un peu déroutants, l'installation et l'utilisation en elle même n'est pas triviale, etc.
Je ne suis allé assez loin pour savoir si la personalisation d'applis est plus simple.

Il les as, du moins dans la version que je connais

**NiamorH** · 22/08/2007, 15h07

Envoyé par Miles

Le mécanisme de signaux et slots est très efficace car il permet de communiquer entre threads.

Est-ce vraiment nécessaire ? Faire intervenir des slots dans un thread différent de celui du signal serait à mes yeux une mauvaise conception qui apporte plus de risques qu'autre chose.

Envoyé par Miles

ou dans le même thread de manière transparente en utilisant le meilleur mécanisme.

La j'ai pas compris.

Envoyé par Miles

Il n'y aucun outil en C++ pur qui permet de faire ce que Qt propose.

A part le fait d'être thread safe ce qui n'est pas un critère déterminant pour moi, bien sur que si. Que vois tu que fait le signal/slot de Qt qu'on ne puisse pas faire en C++ pur?

@koala01 pour le dock et l'anchor, autant pour moi alors ! Pour s'en mordre les dents c'est de Coluche.

**Matthieu Brucher** · 22/08/2007, 15h17

Ah non, c'est super pratique et au contraire, il faut bien prévenir différents threads, non ?
Exemple enfantin :
Tu as un chat de discussion, un thread GUI et un thread pour la gestion du réseau. Dès qu'un paquet arrive sur le réseau pour toi, le thread réseau envoie un signal au thread GUI avec le nouveau message. De même le thread GUI envoie au thread réseau la phrase qu'on vient de taper après avoir appuyé sur envoyer.

Ce n'est pas un problème de conception, c'est bien une solution à un problème récurrent qu'est la communication entre thread.

Ensuite, Qt peut utiliser ce mécanisme lors de signaux entre threads (pompe à message) ou un simple appel à la fonction quand l'objet auquel on envoie le signal appartient au même thread.

En fait, on reprend le principe des GUI dans lequel il y a toujours une pompe à messages et on se dit qu'il y en a une dans chaque thead.

**Alp** · 22/08/2007, 17h55

Cette après-midi je n'étais pas dispo, sinon je serais intervenu instantanément.

Premier point : IHM
Les IHM en C++ c'est pour la plupart des usines à gaz, en exagérant un peu. Seulement, Qt gère ça très bien, avec comme Miles l'a dit un système signal/slot inégalé encore en C++, à ma connaissance.
De plus, pas besoin d'utiliser moc et compagnie. qmake gère tout ça très bien, et pour peu qu'on ait un bon IDE sous la main, ou un éditeur du genre vim/emacs, on peut automatiser tout ça avec un simple raccourci. C'est bien ce qu'on fait en C# non ? Un designer, puis on clique sur des boutons, bam les fichiers sont générés, un autre bouton et hop tout est compilé. De plus, pas besoin de framework. Installer Qt n'est pas si dur, et sur developpez on couvre quand même 2 groupes d'IDE pour l'installation. Et puis c'est toujours pareil : on compile et on ajoute les répertoires pour les entêtes et le linker. Je ne vois pas ce que C++/Qt a à envier à C#.

Deuxième point : C++ par rapport aux autres langages (fonctionnels, logiques, à faible typage ...)
Le C++ supporte ou permet d'implémenter ce qu'il faut pour supporter ces paradigmes. Cependant, ici c'est l'histoire du marteau et du tournevis ... Sauf pour la programmation fonctionnelle. Mais bon les DSEL avec comme langage hôte C++ c'est quand même pas si dur à gérer. Donc si un projet nécessite vraiment d'implémenter un DSEL pour supporter tel ou tel paradigme de programmation, ca n'est pas tellement compliqué. Mais peut-être qu'utiliser un autre langage s'avèrera plus approprié.

Pour les optimisations du compilo, c'est quand même assez correct ... Les compilos réputés sont assez bons dans ce domaine, et en progrès constant.

Je tiens à insister sur le fait que le C++ est un langage qui permet tant de choses, et pas de framework derrière. Les meilleures bibliothèques (Boost pour les outils génériques, Qt pour l'IHM avec un gros support XML/Réseau/BDD [...], ...) point de vue technique et utilité combinées à une bonne utilisation du C++, c'est un duo gagnant. Ce n'est pas dur de les intégrer à un projet, elles possèdent tout ce qu'il faut pour faciliter le développement, ... C# et Java, pour ne citer qu'eux, se retrouvent assez vite rattrappés.

**JolyLoic** · 22/08/2007, 17h56

Aux (avant) dernières nouvelles, tout ce que fait moc est faisable en C++ moderne sans passer par du préprocessing.

Simplement, à l'époque, et même maintenant pour une plus grande portabilité, ces techniques n'étaient pas utilisables.

Quant à qmake, on put très bien s'en passer, il n'est en rien nécessaire à Qt.

screetch · 22/08/2007, 18h03

si on se passe de qmake il faut s'occupper de moc.

Comment puis je faire pour integrer mes sources Flex/Bison qui sont dans mon projet a un projet Qt ?

Je ne dis pas que Qt est nul, je dis qu'ils ont implemente eux memes des choses qui sont implementees de base en C#, comme les priprietes et l'introspection.

**loufoque** · 22/08/2007, 18h05

mais beaucoup plus contraignant que ce que permet un langage avec un support direct.

Ce n'est absolument pas contraignant à utiliser une fois qu'on a conçu les bons outils pour le faire. Concevoir ces outils peut être cependant assez contraignant, mais il s'agit a priori d'une réalisation unique.
Il est évident, par exemple, que de créer un DSEL pour programmer de manière spécifique n'est pas trivial, même avec Boost.Proto.

**Alp** · 22/08/2007, 18h05

Je ne te dis pas de te passer de qmake, mais de le rendre transparent grâce à ton IDE/éditeur avancé.

**Matthieu Brucher** · 22/08/2007, 18h06

Envoyé par screetch

si on se passe de qmake il faut s'occupper de moc.

Si tu le fais à la main, avec CMake ou SCons, c'est automatisable.

**loufoque** · 22/08/2007, 20h31

Les IHM en C++ c'est pour la plupart des usines à gaz, en exagérant un peu. Seulement, Qt gère ça très bien, avec comme Miles l'a dit un système signal/slot inégalé encore en C++, à ma connaissance.

C'était ironique ?
Parce que bon Qt c'est une grosse usine à gaz qui veut tout faire, ça utilise un préprocesseur bidon (qui peut permettre d'écrire du code non sûr et non type-safe) pour implémenter certains trucs qu'on fait parfaitement en C++, ça utilise des pointeurs dans des interfaces publiques -- souvent à la place de références -- et des allocations dans tous les sens avec une gestion des ressources pas claire (c'est toujours mieux que wxwidgets bien entendu)

**Alp** · 22/08/2007, 20h40

Oui, c'est très criticable. Seulement, FLTK, wx, gtkmm et consorts sont dépassés de loin.
Mais aux débuts de Qt, les points que tu abordes n'étaient pas si critiqués je pense. L'accent a été mis dessus après je pense.

Vraiment il est dommage que ça n'utilise pas quelques petites choses apportées et reconnues ces dernières années...

Sinon, on peut aussi parler de Adam & Eve ... Mais c'est autre chose. Je n'ai jamais essayé par contre. Quelqu'un peut apporter des précisions ?

**Davidbrcz** · 22/08/2007, 21h04

Juste pour mettre mon grain de sel.
wxWidgets tient très bien la comparaison avec Qt quand on a compris que ces deux framework ont une vision très différente de la conception d'IHM.