Bon j'ai essayé de rester bref et d'aller droit au but, mais j'ai quand même inclus des arguments précis en annexe, pour ceux qui sont désireux d'en savoir plus.
Admin : si tu trouves que c'est trop hors-sujet ici, merci de déplacer dans Forum Pc - Prog C/C++/C#.
Kevin Kofler :
* GCC est écrit en C.
* Le nouveau linker de TIGCC est écrit en C.
etc.
Si ce ne sont pas de gros logiciels, c'est quoi?
Moi je pensais plutôt à l'intégralité de KDE, à Mozilla, à BeOS et toutes ses applications, etc... GCC est précisement un exemple de gros logiciel en C qui n'est pas une réussite. (1)
Ben, c'est une incompatibilité, donc disons que c'est un inconvénient des deux. Mais c'est la faute de M$, pas de MinGW. 
Avec toi c'est toujours la faute de Microsoft on dirait. Faut surtout pas chercher plus loin.
clair que le concept objet, pkoi s'en passer ?
Parce que ça donne des programmes plus gros et plus lents.
C'est le même argument que << le C c'est nul parce que ça segfault. >>
- le programmeur y est pour beaucoup.
- dans le cas du C++, le compilateur y est également pour beaucoup. (2)
Exemples concrets : BeOS, AtheOS, Blackbox/Fluxbox, Opera... ceux-là sont réputés pour être light et rapides, pourtant ils sont en C++.
Et enfin, mais là évidement tu n'es pas d'accord mais je crains que tu ne puisses rien y faire, pour l'industrie actuelle "gros et lent" n'est absolument pas un inconvénient. Plus le temps passe, plus le facteur "gros et lent" diminue, avec les nouvelles machines plus rapides et ayant plus de RAM. C'est la triste réalité des choses.
Pas toujours. Les classes c'est très pratique et ça ne change ni la taille ni la vitesse, par exemple.
Si, justement, ce sont les offenseurs numéro 2. Le numéro 1, ce sont ces !@#$%^&*() de templates. (Les macros, c'est pour les chiens?) Jamais entendu de pénalité d'abstraction?
Jamais entendu parler de réutilisabilité ? Tes considérations ne sont pas les mêmes que les autres programmeurs, tu l'ignores un peu trop souvent. Les templates sont precisement un atout considérable du C++, qui en fait un langage à deux niveaux (execution statique et dynamique), ce qui est infiniment plus puissant que les pauvres macros du préprocesseur. (3)
Ces inconvénients sont largement compensés par la facilité de maintenance et la clarté du code que ça apporte.
Je ne suis pas d'accord. Il ne faut pas sacrifier la qualité du code à la fainéantise des programmeurs. Vive le C et l'assembleur!
Je pense qu'il faudrait que tu retournes dans les années 80, là où tu as ta place. A mon avis il te manque une certaine ouverture sur l'extérieur pour constater que le monde a bien évolué depuis. Aujourd'hui dans l'industrie c'est C++ & Java, dans la recherche c'est principalement langages fonctionnels (que tu rejettes également) et/ou orientés objet, dans les jeux videos c'est C++ partout (même sur GBA), dans le logiciel libre, longtemps retardé par l'absence de compilateur C++ digne de ce nom, ça arrive aussi : cf. KDE, Mozilla, la grande majorité des API graphiques, Blackbox & Fluxbox, apt-get, CUPS, ... la liste est longue.
Je dirais pour terminer que le C++ est loin d'être idéal, mais il est quand même considérablement plus adapté que le C pour faire des logiciels qui commencent à être complexes au point de vue modélisation. Le C reste néanmoins indispensable en système et peu être utilisé pour les petits logiciels (le nouveau linker de TIGCC le montre bien).
Et pour recentrer le débat sur les TI, j'ajouterai que le C++ sur TI est possible mais contreignant à cause des compilateurs actuels, que d'autres langages orientés objets sur TI seraient parfaitement envisageables, et que pour finir, le C++ sera définitivement une réalité sur les prochaines calculatrices HP.
Annexe.
(1) Mais comme il doit se trainer des siecles (que dis-je
) de compatibilité avec des trucs obsoletes, on peut pas vraiment faire autrement. GCC n'est pas structuré (cf. la branche ssa-tree qui vise à reformer la totalité de l'optimisateur), et des situations abérantes se sont produites, comme par exemple l'existance de deux moyens bien distincts d'écrire des back-ends, l'un completement obsolete et toujours très utilisé et l'autre nouveau et que personne n'a pris le temps de documenter pendant un bout de temps. Du coup les deux sont utilisées en même temps. Une belle réussite.
(2) L'overhead dû au paradigme de l'orienté objet se retrouve principalement dans le dispatch dynamique utilisé pour appeller une méthode dans une hierarchie de classes. C'est d'ailleurs un sujet de recherches très ouvert actuellement, et pas mal de résultats interessants sont disponibles.
- méthodes de dispatch alternatives qui s'optimisent plus facilement que les vtable de GCC : cf. les travaux sur le compilateur Eiffel ;
- optimisations aggressives au moment du link : resultats remarquables au niveau d'un compilateur Modula-2 experimental ;
- etc...
(3) cf. "Effective C++" et "More Effective C++" de Scott Meyers.
Ces deux references reviennent souvent lorsqu'il y a un flamewar sur le C++ (par exemple sur la mailing list de développement GBA il y a environ 2 ans, où la plupart des professionnels du milieu se retrouvent), et ce qui revient souvent c'est que ceux qui ont lu ces livres savent de quoi ils parlent, les autres assez rarement.
Les templates sont le moyen ultime d'écrire du code à la fois efficace (en vitesse) et générique c'est à dire réutilisable. C'est pourquoi la STL les utilise. Il n'y a aucun moyen en C de faire à la fois aussi efficace et aussi générique.
Il doit vraiment être génial si c'est le cas... La source prend combien?
pour comprendre 
) ?