[Debat] C++ et IHM

screetch · 22/08/2007, 11h42

Bonjour,

Ceci est un fork du passionnant débat du topic: "C et C++, mythe et réalité".

Afin de conserver les discussions qui sont de trés grande qualité, mais de faire en sorte que chaque sujet reste disctinct, nous avons décidé de les séparer ansi.

J'espère que vous comprendrez notre démarche.
Si vous avez des remarques concernant cette opération, merci de nous les adresser par mp.

r0d, pour l'équipe de modération.

Envoyé par Mongaulois

C'est vrai, mais avec le C++, tu peut tous faire (je ne vois pas de contre exemple). Aprés, je pense que le c++ est un trés bon language pour comprendre les différents concept de programmation. Et si tu as bien tout assimiler, passer à un autre langage est plus simple.

Tu peux tout faire mais peu de chances que ce soit le meilleur outil pour tout.
Une webapp est mieux ecrite en Java qu'en C++.

Pour les interfaces graphiques, C# montre clairement sa superiorité.

C'est justement de cela dont parlais dj.motte, et j'aime beaucoup cette remarque : Se borner à un seul langage que l'on sacralise, c'est bon pour les novices de l'informatique...

Connaitre plus de concepts est important, y'a pas que la POO dans la vie!

**Matthieu Brucher** · 22/08/2007, 11h51

Envoyé par screetch

Une webapp est mieux ecrite en Java qu'en C++.

Pour les interfaces graphiques, C# montre clairement sa superiorité.

On fait entrer dans la danse les autres langages tant qu'à faire ? Parce que les applis Java sont surtout côté client et même on parle souvent de Java alors qu'ne fait c'est du JS, et côté serveur, c'est plus PHP, Perl, Python, Ruby que Java.

**r0d** · 22/08/2007, 11h53

Envoyé par screetch

Pour les interfaces graphiques, C# montre clairement sa superiorité.

Je m'inscrit en faux. J'ai fais beaucoup de c# ces derniers temps (et je risque d'en faire encore beaucoup), et pour faire une simple boite de dialogue jolie, ok, il n'y a pas mieux. Mais dés que ton ihm nécessite du graphisme (images qui bougent, masques qui changent, etc.), d'une part ça rame pire que java, et d'autre part, c'est extrêmement difficile à optimiser.

screetch · 22/08/2007, 12h10

Je parle de webapp, pas de pages generees par script. Je parle plutot de Tomcat, Cocoon, etc, qui sont des outils Java. Je suis pas a mon aise dans ce sujet mais je sais que les sites Web sont soit scriptes en PHP/ASP/perl/autres, soit sont geres par des machines virtuelles Java qui repondent aux requetes. Mais l'important est que le C++ n'apparait jamais dans cette liste !

Niveau IHM j'en fais pas car j'ai horreur de ca, mais en ce qui concerne l'ergonomie et la puissance de l'IHM cree, C# est superieur au C++ en general. Il existe des cas a adapter bien sur selon ce que l'on souhaite faire, mais il me semble que c'est justement le but du topic que de dire que tout BON programmeur ne se cantonne pas a un seul langage et essaye d'utiliser l'outil adapte a son besoin. =)

**nikko34** · 22/08/2007, 12h24

Envoyé par screetch

Niveau IHM j'en fais pas car j'ai horreur de ca, mais en ce qui concerne l'ergonomie et la puissance de l'IHM cree, C# est superieur au C++ en general.

ben comme ya pas d'IHM en C++ standard, difficile de faire une comparaison...

**Alp** · 22/08/2007, 12h27

Un bon petit Qt tient LARGEMENT tête aux IHM standards Java ou C# je pense, quand même ...

screetch · 22/08/2007, 12h41

Certes Qt y arrive pas mal mais vous admettrez que c'est extremement lourd! Il y a une phase de pre pre processing, des macros, un outil make specifique, etc.

Donc CERTES on peut tout faire en C++ MAIS dans ce cas la C# propose en natif tout ce que Qt a du faire a la paluche a grand renfort d'etapes supplementaire de compilation et autres macros.

DONC C# est un peu mieux adapté a l'IHM (ca a ete limite fait pour) MAIS on peut le faire en C++, c'est juste PLUS LOURD.

**koala01** · 22/08/2007, 12h47

Envoyé par screetch

Certes Qt y arrive pas mal mais vous admettrez que c'est extremement lourd! Il y a une phase de pre pre processing, des macros, un outil make specifique, etc.

Donc CERTES on peut tout faire en C++ MAIS dans ce cas la C# propose en natif tout ce que Qt a du faire a la paluche a grand renfort d'etapes supplementaire de compilation et autres macros.

DONC C# est un peu mieux adapté a l'IHM (ca a ete limite fait pour) MAIS on peut le faire en C++, c'est juste PLUS LOURD.

Ce n'est pas beaucoup plus lourd que de devoir gérer n'importe quelle autre bibliothèque d'IHM...

Tu serais sans doute surpris de voir tout le code qui se cache réellement derrière le simple fait que, en double cliquant sur quelque chose dans un RAD, le bouton apparaisse "comme par magie" sur l'apperçu du formulaire en cours de traîtement...

Mais, l'un dans l'autre, que tu regarde du côté de .NET, des différents RAD C++, ou du côté de java, le code qui fournit la bibliothèque graphique reste aussi lourd partout...

La seule différence vient peut être du fait que QT ne fait pas mystère du code qui est utilisé pour créer cette bibliothèque

screetch · 22/08/2007, 12h57

Qt a du rajouter tout un systeme de RTTI avec des slots/signaux et des properties. Ces choses ajoutees en surlangage necessite un preprocessor, donc je trouve quand meme que c'est a la frontiere du C++. Tu ne peux pas compiler une appli Qt sans utiliser le compilateur MOC fourni avec Qt.

Toutes ces etapes supplementaires n'existent pas en C#

Pour decrire la hierarchie de classes en Qt les ptits gars de Trolltech ont du generer des metaclasses "a la paluche" et creer un systeme de RTTI qui n'est disponible que grace a MOC.
C# possede tout cela en natif

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)

Donc je reponds : Certes tu peux faire ton IHM en C++ avec Qt, mais le C# est plus adapte a l'IHM, si ton seul but est de faire une IHM fais la en C#. Si ton but est de t'interfacer avec une lib C++ fais du C++.

Un exemple couillon, un jeu video qui va sortir est fait en C++ integralement mais l'editeur de map est fait en C# et pas en C++! pour profiter du langage qui est bien mieux adapté

Ca me fait penser a quelqu'un qui utilise son marteau partout, et un jour on lui presente un tournevis, et il repond "non je veux utiliser mon marteau je fais tout avec". Ben ce gars la tout le monde comprend qu'il est debile de se faire chier avec son marteau alors qu'il pourrait utiliser le marteau pour planter ET le tournevis pour visser.
Donc je ne valide pas l'argument comme quoi on PEUT faire des IHM en C++, car pour moi je sais qu'on PEUT mais le langage n'est pas adapté, mieux vaut donc utiliser un langage specialement créé pour ca.

C'est comme dire qu'on peut faire de la POO en C, certes mais au prix d'une surcouche assez epaisse alors que le C++ est prevu pour ca.

Donc connaitre plus de langage que le C++ permet de s'adapter et de prendre l'outil ideal pour resoudre un probleme.

**koala01** · 22/08/2007, 13h33

Mais les gars de chez microsoft qui ont créé ce que tu dis que C# a cela en natif... que crois tu qu'ils ont fait

La seule différence, c'est que tu ne vois sous C# que la partie visible de l'iceberg, alors que tu peut accéder à l'ensemble du code source de QT...

Ce n'est pas pour rien que les différents frameworks sont si lourds à installer.

Regarde une installation "classique" de BCB, cela te fait environ 600 Mb d'espace disque nécessaire.(BCB 6 "entreprise")

Regarde l'espace requis pour n'installer que le stricte minimum pour C# (C# et framework 2.0), tu tourne à 1.1Gb (968Mb sans framework)(.NET 2005)

Regarde l'espace nécessaire à QT, exemples, DLL debug, sources, aide et tout compris, ca tourne aux alentours de 2 Gb, mais si tu ne regarde que les dossiers réellement utiles (bin, include, lib, plugins), ca tourne à seulement 730 Mb (QT 4.3.1 snapshot)

Finalement, cela se tient dans un mouchoir de poche... Mais ça reste quand meme C# qui va nécessiter le plus.

Je ne connais pas particulièrement java, mais, entre la JVM, le framework nécessaire à la création d'interface et le RAD, on doit vraissemblablement tourner dans les mêmes eaux, non

Alors, venir dire que le fait d'obtenir une IHM avec C++ est plus lourd, c'est nier les faits...

Et je ne parle pas des autres possibilités d'obtenir uneIHM e C++ (WxWidget, par exemple) qui sont vraiment "light".

**koala01** · 22/08/2007, 13h36

La seule différence, c'est que

Borland fournis quelque chose de tout à fait fermé(impossible d'avoir le code source d'origine)
.NET fournis aussi quelque chose de tout à fait fermé
QT n'a pas peur de montrer son code source

screetch · 22/08/2007, 13h40

Certes... ^^

Ce que je dis c'est que le taff qui a ete fait chez Crosoft, Inc. permet a un utilisateur lambda (developpeur certes mais utilisateur du langage et de la lib) de croiser les pieds sous la table, de coder en C# sans se preoccupper de tout cela.

Alors que le programmeur qui utilise Qt va devoir gerer son qmake, son moc, ses macros.

Apres la lib finale a les mems fonctionnalités.

Tout comme tu peux faire des structs derivant les une des autres en C en faisant toi meme les methodes "virtuelles", et C++ ne fait pas differemment, mais tu n'as juste pas besoin de t'en soucier en C++, c'est integre dans le langage.

Je vois ici le meme genre d'entetement qui a pourtant ete critique trois pages avant, a savoir que y'a plus simple mais comme je peux le faire aussi en C++ a grand renfort d'outils externes alors jle fais quand meme en C++.

Nous sommes exactement a des annees lumieres du topic original.

Note pour plus tard : IHM, sujet sensible...

**epsilon68** · 22/08/2007, 13h51

Envoyé par screetch

Alors que le programmeur qui utilise Qt va devoir gerer son qmake, son moc, ses macros.

justement avec qmake , tu ne t'occupes pas de MOC, et en fait tu ne t'occupes de rien puisque qmake genere le bon makefile qui va bien.

Un pre-processeur (MOC) n'a rien d'alarmant, c'est meme élégant je dirais.
bon nombre de choses ne sont pas intégré dans le language, que ce soit C# ou java ou autre... et pourtant il faut bien avancer non ?

on ne peut quand meme pas tout attendre du language et/ou du framework, enfin je ne pense pas.

**koala01** · 22/08/2007, 13h57

Attention, je ne voulais pas du tout donner l'impression d'un entêtement de mauvais aloi, je voulais par contre réagir sur le fait que tu disais que C# était "plus léger"... tu voulais sans doute parler de légèreté d'utilisation, et j'ai, visiblement à tord, interprété cela du point de vue du poids de l'installation...

Je reconnais volontiers que Trolltech n'a pas *forcément* cherché la facilité d'utilisation et a préféré laisser la plus grande latitude à l'utilisateur, alors que microsoft a cherché à rendre l'utilisation la plus simple possible... en sacrifiant à la latitude d'utilisation...

Je n'émet aucun avis sur celui qui a raison, afin de laisser chacun libre de préférer l'un ou l'autre

**MatRem** · 22/08/2007, 14h04

Moi aussi je trouve Qt un poil lourd à utiliser, notament à cause de ce fameux moc...
Maintenant j'utilise gtkmm qui je trouve vraiment géniale à utiliser...

screetch · 22/08/2007, 14h07

ah non niveau codage interne ca ne m'interesse pas (enfin si ca m'interesse) mais je voulais par la comparer le fait de creer une petite appli avec une IHM, je ne parlais pas de developper une lib come Qt en fait.

Apres comment c'est fait a l'interieur, houla! ^^

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

Envoyé par screetch

Certes... ^^

Ce que je dis c'est que le taff qui a ete fait chez Crosoft, Inc. permet a un utilisateur lambda (developpeur certes mais utilisateur du langage et de la lib) de croiser les pieds sous la table, de coder en C# sans se preoccupper de tout cela.

Alors que le programmeur qui utilise Qt va devoir gerer son qmake, son moc, ses macros.

Apres la lib finale a les mems fonctionnalités.

Tout comme tu peux faire des structs derivant les une des autres en C en faisant toi meme les methodes "virtuelles", et C++ ne fait pas differemment, mais tu n'as juste pas besoin de t'en soucier en C++, c'est integre dans le langage.

Je vois ici le meme genre d'entetement qui a pourtant ete critique trois pages avant, a savoir que y'a plus simple mais comme je peux le faire aussi en C++ a grand renfort d'outils externes alors jle fais quand meme en C++.

Nous sommes exactement a des annees lumieres du topic original.

Note pour plus tard : IHM, sujet sensible...

As tu déjà essayer d'utiliser Qt avec les intégration dans visual?