Discussion :

[screetch]

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.

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]

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]

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]

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]

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]

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

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

[swirtel]

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 !

Ah si si, au boulot, j'utilise C++ Builder et Delphi pour écrire une application Web. :-)

Vive la galère

[loufoque]

C'est parce que tu n'utilises pas les bons outils.
Au contraire, C++ est bien plus adapté pour faire ce genre de choses que les langages de script populaires.

En particulier, du côté performance et extensibilité, en C++, les applications web peuvent réellement être écrites de manière asynchrone, sécurisée, et très réactive, en décomposant l'acceptation, le chargement et la gestion des requêtes.
Bien évidemment ce n'est possible qu'avec FastCGI ou SCGI.

Voir par exemple Boost.CGI, bibliothèque en cours de développement.

Il y a aussi simplement des abstractions de haut niveau simples pour créer facilement des "scripts CGI" en C++, et non pas des serveurs complets, come cgicc.

[swirtel]

tu perds aussi pas mal de temps à recompiler le projet quand tu veux simplement corriger un bug, C++ est p-e bien, mais oublie borland à ce niveau là.

Je préfère de loin m'amuser à développer en D pour obtenir la même qualité.

Le problème que j'ai, est que j'utilise de mauvais outils, que mes classes C++ sont partagées avec Delphi, et Java via un binding SWIG.

D'ailleurs, je me demande si le partage de classes via un connecteur C++->Delphi écrit en C++ est intéressant par rapport à des outils comme COM, & Co.

[Alp]

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]

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]

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.

[Alp]

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

[loufoque]

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.

[Matthieu Brucher]

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]

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]

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]

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.

[Matthieu Brucher]

Le point négatif est que wxWidgets n'est pas autant objet que ne l'est Qt.