Discussion :

[deadalnix]

Oui, sauf que dans l'opération, on a perdu ce qui était sensé faire la force du C++, la possibilité de faire du bas niveau.

L'exemple de l'expression template est caractéristique : le seul moyen de faire une lib de calcul vectoriel/matriciel efficace en C++ est horriblement complexe.

Ce qui se passe dans la pratique, c'est que dans 95% des cas, tu ne peut résoudre tes problèmes de programmation comme un grand car le langage ne t'en donne pas les moyens. Tu es obligé d'attendre qu'un roxor du problème et du C++ et des différents compilos sorte une lib.

Alors que les expressions template, c'est pas compliqué en soit. Le principe est simple. C'est juste horrible à mettre en place en C++. Alors qu'avec de test à la compilation (en D, static if) et du typage automatique (comme en Caml, ou bien avec le type auto de D) ça se fait tout seul.

C++0x apporte pas mal de choses au niveau de la metaprogrammation (qui existent déjà dans D ceci dit) qui rendrait une bonne partir de cet argument caduque. Mais le fait est la que C++0x, il est pas la.

Mais bon, on peut aussi partir sur d'autres points que la metaprogrammation. L'absence de standard au niveau des binaires est aussi un belle saloperie. Du coup, pas moyen de linker quoique ce soit.

Pour le langage qui exprime mieux la généricité, regarde du coté de D. Il est très loin d'être parfait comme langage (principalement, au niveau des libs standards, il ne devrait pas y avoir de s).

C'est vrai que C++ permet d'exprimer pas mal de choses à ce niveau la, et c'est ce qui m'a retenu sur ce langage pendant longtemps. Peu de langages permettent autant au niveau de la metaprogrammation. Il n'empêche qu'il y en a qui font mieux (D est un exemple). Et même s'il n'y en avait pas qui faisaient mieux, ça ne voudrait de toute façon rien dire sur la façon donc C++ le fait.

[Alp]

La "mocheté" et la "complexité" des templates permet de générer du code, il ne s'agit pas uniquement de généricité. Notamment, il y a un système qui permet de générer la parallélisation de filtres pour des signaux, tout ça à la compilation.

Après, entre nous, D n'a pas 20 ans d'histoire à se trimballer, c'est normal qu'ils aient des "brand new features" sans soucis. C'a ses avantages et ses inconvénients. Et le système de type de D est très proche si ce n'est le même que celui de C++, à peu de choses près. A part la syntaxe (+1 à D, on reprend la syntaxe des fonctions mathématiques, on est + conscient qu'on a des fonctions sur des types)...

Mais pour moi avoir la programmation générique et générative d'un côté, grâce aux templates, et l'OO de l'autre côté, donc du multi-paradigme, ça ouvre la porte à tellement de choses que je ne quitterai pas le C++ pour Java ou C# de si tôt... D'ailleurs, une bonne lecture à ce sujet (multiparadigme) : Multiparadigm Design for C++, de James O. Coplien.

Et C++0x, bah plutôt que de te plaindre du retard, aide-les ?

Ce qui se passe dans la pratique, c'est que dans 95% des cas, tu ne peut résoudre tes problèmes de programmation comme un grand car le langage ne t'en donne pas les moyens. Tu es obligé d'attendre qu'un roxor du problème et du C++ et des différents compilos sorte une lib.

Oui, car beaucoup de gens sont des personnes qui se content toujours du minimum, qui n'apprennent jamais à fond les choses, qui se plaignent 99% du temps de leur job, bref qui ne vont jamais au fond des choses. Personne les oblige à faire du C++.

Par contre, 100% d'accord pour la compatibilité binaire. L'une des choses qu'on est "contents" d'hériter du C

[Florian Goo]

Puisque ça parle de D (auquel j'ai commencé à m'intéresser un moment), j'en profite pour poster un lien vers un topic en parlant : http://www.developpez.net/forums/d78...ute/langage-d/
Peut-être pourrait-on le déterrer, histoire de ne pas être off-topic.
Je trouverais ça intéressant d'aller plus loin dans le débat .

[Florian Goo]

Il y a de très nombreuses fonction dans le C++ qui interagissent très mal entre elles. Par exemple, si l'on veux faire du calcul vectoriel grâce à la surcharge des opérateurs.

Qu'est ce que tu vas utiliser comme retour ?

Ou bien tu le fais par valeur, mais dans ce cas tu pourris tes perfs en faisant des copies dans tous les sens. Ou bien tu retournes un smart pointer mais c'est le même combat (et en plus, c'est pas vraiment le langage mais une surcouche). Ou bien tu retournes une référence et ta gagné la fuite de mémoire (tu n'as acun moyen de l'esquiver).

Et la RVO, alors ?

[Alp]

Et la RVO, alors ?

Mentionnée ici d'ailleurs, mais tu fais bien de le rappeler

[deadalnix]

Mais pour moi avoir la programmation générique et générative d'un côté, grâce aux templates, et l'OO de l'autre côté, donc du multi-paradigme, ça ouvre la porte à tellement de choses que je ne quitterai pas le C++ pour Java ou C# de si tôt... D'ailleurs, une bonne lecture à ce sujet (multiparadigme) : Multiparadigm Design for C++, de James O. Coplien.

Justement, on a ajouté tout ça sur le C. Qui n'a jamais été fait pour. En fait, on a tellement ajouté à C qu'on a un langage qui n'a plus rien a voir et traine des vielles casseroles comme tu le dis très justement.

La base du C++ n'est pas saine.

Et si C++0x promet de résoudre certain problèmes, d'autres sont la a prioris ad vitam eternam.

Un autre exemple : la RVO, c'est bien, mais c'est incompatible avec la surcharge des opérateurs. Les fonctionnalités sont la, simplement, le mécanique n'est pas bien huilée.

Du C++, j'en ai bouffé plein, je sais ce qu'il est possible de faire, mais j'ai aussi bien vu ou étaient les limites.

[Florian Goo]

Une ré-ingénierie du C++, j'en ai déjà rêvé. C'est ce que D semble vouloir proposer. Je réitère ma proposition. On continue le débat ici : http://www.developpez.net/forums/d78...ute/langage-d/ ? Ce serait très intéressant !

[Luc Hermitte]

Si tu vois pas de grande différence entre le C/C++ et le Java, c'est qu'il te reste encore beaucoup de chemin jeune padawan

Ne parlons même pas de la différence entre le C et le C++ ...

Pour les niveaux, comme d'hab, manque de recul et de connaissance des voisins.
Il n'y a pas deux directions, haut vers bas. Mais plusieurs axes, et chaque langage va aller plus ou moins loin sur chaque axe. Java&C# iront loin sur la réflexivité dynamique, C++ s'en sort à peu près sur la réflexivité statique où les deux autres sont absents (cf boost.unit dont le principe fut réfusé pour Java), Java&C# s'en sortent à peu près sur la généricité, C++ va loin sur la généricité (allez donc faire des fonctions génériques sur énumérés en Java...), C&C++ vont loin sur l'axe du hard (a.k.a. bas niveau), etc.
Et je peux continuer à trouver d'autres axes qualifiés de "haut niveau" sur lesquels Java est en retard vis à vis du C++ comme p.ex. la programmation par contrat.
Bref, cette dichotomie haut niveau vs bas niveau est complètement désuète aujourd'hui en regard du multiparadigme et autres choses supportées par les langages.


Les problèmes du C++ ?
- Langage particulièrement méconnu et mal enseigné. D'où les mauvais réflexes, vos segmentation faults etc
- Langage particulièrement méconnu et mal enseigné qui génère des populations qui ne le connaissent pas mieux
- Langage complexe qui rend le support par des outils d'analyse automatique difficile ;


Pour vos histoires de complexité de mise en œuvre des expressions templates pour faire du calcul vectoriel performant. Oui. Et ? Ca existe déjà et ça marche. Où est le problème? Nos voisins ont des frameworks qui font des choses compliquées à leur place. Leur demande-t-on de repartir de 0 ? Je n'ai pas l'impression que c'était le topic de ce troll ci. Le D est trop maigrichon pour être comparé aux monstres de production à la chaine que sont Java&C# -- sur le thème de la productivité.

[deadalnix]

Pour vos histoires de complexité de mise en œuvre des expressions templates pour faire du calcul vectoriel performant. Oui. Et ? Ca existe déjà et ça marche. Où est le problème?

Le problème, c'est que justement, ce soit très dur et complexe. Non pas parce que le concept d'expression template soit complexe (bon, c'est pas trivial, mais rien de très méchant non plus), mais bien parce C++ à un système de template mal pensé dans son ensemble. C++0x apporte de bonnes solutions à tout cela.

En fait, le soucis des expression templates est un soucis comme un autre. Le C++ est remplis de trucs du genre. Le move constructor en est un autre aussi.

Je cite ces exemples car ils sont très connus, mais bien évidement, du fait qu'ils sont très connus, des solutions clef en main existent. Par contre, plus rien n'existe quand tu as un besoin plus particulier, et la, il faut te farcir des truc pas tristes.

En fait, je ne penses pas apprendre à beaucoup de monde que la façon de coder en C et en C++ n'a plus grand chose à voir. Pourtant, C++ s'est construit en ajoutant des choses à C. Il est clair que cela à commencé avec du C with classes. Puis petit à petit, de nouvelles pratiques sont venues, et on a révisé le C++ afin de coller avec ces nouvelles pratiques.

En sachant on on allait depuis le début, on aurait sans doute pu faire un langage tout aussi complet mais bien plus facile. C'est ce que propose D.

Alors bien sur, ça n'annonce pas la mort du C++, ne serait-ce que pour la quantité pharamineuse de code qu'on ne va pas s'amuser à refaire en D pour le plaisir. Mais dans les domaines ou le code vieillis très mal (comme pour le JV par exemple), ça me semble être un choix à considérer sérieusement.

D n'a pas la prétention de refaire java ou C#, mais plutôt C++. Java et C# ont choisis de simplifier la langage, mais en sacrifiant beaucoup en possibilités. Si dans la pratique ce qui est sacrifié n'est pas gênant pour certaines application, ça l'est pour d'autres.

D'autres langages vont encore plus loin que Java ou C#, comme python ou ruby. On fait des choses encore plus rapidement, mais cela n'est pas possible pour encore plus d'applications.

[pseudocode]

Bref, cette dichotomie haut niveau vs bas niveau est complètement désuète aujourd'hui en regard du multiparadigme et autres choses supportées par les langages.

Hum... C'est une manière de voir les choses. On pourrait aussi dire que "le multiparadigme est complètement désuet en regard de la facilité d'intégration de modules écrits dans différents langages dédiés". C'est l'approche proposée par .NET (et dans une moindre mesure Java).

L'approche de développement monolithique (toute l'application codée en C++) n'est plus la seule solution possible. Aujourd'hui la moindre application web utilise au moins 5 langages (html, css, javascript, php, sql) et 2 runtime (browser, serveur http).

Je ne dénigre pas le C++ : j'en reconnais toute la puissance. Mais j'ai l'impression qu'on "rajoute" des paradigmes/fonctions sur ce langage pour en faire une sorte de couteau suisse : impératif, objet, meta-prog, ... et pourquoi pas dans un proche avenir : fonctionnel, aspect, dynamique, garbage collection, ...

Cela rend le langage C++ complexe et la courbe d'apprentissage devient de plus en plus longue. Qui peut se prétendre être un "développeur C++ expérimenté" aujourd'hui ? Un programmeur avec beaucoup d'expérience dans l'un des paradigmes, ou un programmeur qui a expérimenté un peu tous les paradigmes ?

[ego]

désolé, je n'ai pas lu toutes les réponses....

C, C++, Java...D,...E, F.......

Le "problème" de ces langages est qu'ils n'apportent en vérité rien de fondamentalement nouveau.
ok, on peut se "battre" sur la syntaxe plus ou moins simple mais l'essentiel n'est pas là surtout avec les éditeurs modernes.
Je "plus" de Java est essentiellement l'apport d'une standardisation des librairies "utilitaires". On connait le "Java n'est pas qu'un langage", "Java c'est une plate-forme de développement".
Donc de ce point de vue, Java est beaucoup mieux que C ou C++.

Maintenant, je trouve personnellement que les langages que ne font que changer la syntaxe n'apportent en réalité rien au monde informatique. Ce dont nous avons besoin ce sont de vrais nouveaux concepts. Nouveaux ou anciens mis en avant comme la programmation par contrats ou encore l'héritage dynamique.
Des trucs comme l'AOP par exemple me paraissent bien plus intéressants qu'un nieme langage car cela apporte une réelle nouveauté dans le monde de l'informatique.

Donc pour répondre basiquement à la question initiale, il n'est pas envisageable de revenir à C ou C++

[xbrossard]

J'ai eu l'occasion de tester pendant longtemps les langages C++ et C# et pour moi il est évident que C++ est plus puissant que C#:

• Plusieurs paradigmes de programmation: fonctionnel ou objets, programmation générique
• Héritage multiple, difficilement implémentable de manière aussi simple par l'utilisation des interfaces, qui oblige souvent à créer des classes d'implémentation sans rapport avec le modèle applicatif...Essayez d'implémenter un modèle UML avec héritage multiple est difficile en C# ou Java.
• L'utilisation d'un GC en C#/Java de manière systématique est couteux en temps et ne permet pas de gérer de manière élégante des ressources critiques: par exemple, impossible de gérer la fermeture de fichiers de manière implicite tel que le ferait les destructeurs en C++. Le comportement du programme est non déterministe en C#/Java.
• Possibilité d'optimisation beaucoup plus limité en C#/Java du fait garbage systématique, et de l'allocation des objets dans le tas uniquement. En C++, on peut mettre en oeuvre un GC sur certaines classes seulement, et l'allocation d'objet dans la pile est beaucoup plus performant que l'équivalent C#. Ce qui explique qu'un programme C++ bien optimisé sera toujours plus efficace que son équivalent C#, même compilé.
• Plus grande richesse du langage C++ en particulier sur la surcharge des opérateurs, qui permettent vraiment la création de type abstrait de données. La surcharge par exemple de l'opérateur new permet l'implémentation transparente des factory de classes.
• Plus grande richesse dans la gestion de l'encapsulation: notion de classes Amies
• L'utilisation de librairie de méta-programmation en C++ tel que Open C++ offre plus de possibilité que la reflection en C#, avec l'avantage d'être plus performant car fait de manière non dynamique (précompilation du méta-modèle).
• Contrôle de l'accès mémoire plus riche, au travers de l'utilisation des pointeurs mais aussi sécurisé par l'utilisation des références. La possibilité de surcharger les opérateurs d'allocation permettent la gestion mémoire spécialisé pour certaines classes.

tout les autres avantages prêtés à Java et .NET proviennent de leurs librairies, et peuvent être retrouvés en C++ par des librairies externes.
Il est assez amusant d'ailleurs de voir les arguments des défenseurs de ces plateformes, qui me rappelle furieusement l'argumentaire des pro gros-système; à l'époque où j'ai participé à l'installation des systèmes Unix en remplacement des GCOS7, les spécialistes GCOS7 raillaient Unix qui n'avait pas de base de données, ni de moniteur transactionnel intégré au système....c'est sûr qu'il n'avait pas pensé à Oracle et Tuxedo, mais pour eux, un système se devait de tout fournir...quitte à fournir des outils peu performant et très lourd d'utilisation...

[Médinoc]

• OK (encore que, il y a une possibilité limitée de prog générique en C#, et encore plus limitée en java)
• OK
• La destruction déterministe reste possible en C# (interface IDisposable et blocs using).
• Tu confonds C# et java: C# permet l'utilisation de types valeurs complexes et le passage de paramètres par référence.
• C# permet de surcharger pas mal d'opérateurs, même si ce n'est pas à ma connaissance possible pour l'opérateur new.
• OK
• OK
• OK.

Sinon, si tu n'as pas peur d'être un peu verbeux, tu devrais essayer C++/CLI, qui cumule les avantages de .Net (moins plusieurs améliorations syntaxiques de C#, sans parler du C# 3.0) et du C++ natif...

[xbrossard]

• La destruction déterministe n'est pas implémenté correctement en C# par IDisposable, qui n'est qu'un artefact appauvri d'appel automatique de méthode. Il n'y a par exemple aucun mécanisme pour s'assurer que la ressource est libéré au bon moment, c'est à dire quand tout ces accesseurs (=> ayant un lien sur la ressource) ne l'utilisent plus. Il est très facile d'avoir des problèmes si une ressource gérée par using(...) est passé en paramètre d'une méthode appelée dans le using et que cette méthode gère la désallocation de la ressource...(va voir le site http://www.devx.com/dotnet/Article/33167/0/page/ qui te donne un aperçu de la complexité de la chose...)
• Les types de valeur complexe en C# (je pense que tu parle des struct...) est plus limité que les classes (voir toutes les contraintes de création...) et de toute façon, toute struct crée ne sera pas dans la pile mais dans le tas...et donc leur allocation sera plus lente. De plus, il est aberrant que le status mémoire d'un objet soit défini dans son type plutôt que dans son utilisation; une classe doit pouvoir être allouée indifféremment dans la pile ou le tas.
  Pour te donner un ordre d'idée de ce que l'on peut faire en C++ et pas en C#, j'ai crée une classe FixedString<n> avec n entier pour implémenter les chaines de caractères d'une table en SQL; cette classe inclus un tableau de char[n] et ne fait donc aucune allocation dynamique, et si je la déclare dans la pile, sa création n'implique aucun temps pour l'allocation mémoire. Et cette classe dérivant d'une classe FixedString travaillant sur un char* avec une longueur maxi en paramètre, elle offre le même confort et le même contrôle qu'une classe String standard...avec gestion de la troncation automatique ou l'envoi d'exception par exemple...
• La surcharge d'opérateur est un gadget en C# étant donné le peu d'opérateurs possibles...en particulier ne sont pas autorisé les opérateurs d'affectation, d'affectation, opérateurs logique, etc...

Le C++/CLI est malheureusement une aberration qui supprime l'héritage multiple pour l'adapter au .NET...donc n'est pas compatible avec C++

L'utilisation d'un garbage non déterministe, le manque de contrôle sur l'allocation mémoire et la gestion des ressources, le niveau d'abstraction insuffisant...ceci explique pourquoi le C# n'est pas utilisé sur des projets avec de fortes contraintes sur les performances et les ressources tel que les moteurs 3D ou la programmation temps réel...et ne le sera certainement jamais...

[Médinoc]

et de toute façon, toute struct crée ne sera pas dans la pile mais dans le tas...et donc leur allocation sera plus lente

Moult te goures. Ou bien, je n'ai pas compris ce que tu veux dire par "créée".

Pour te donner un ordre d'idée de ce que l'on peut faire en C++ et pas en C#, j'ai crée une classe FixedString<n> avec n entier pour implémenter les chaines de caractères d'une table en SQL; cette classe inclus un tableau de char[n] et ne fait donc aucune allocation dynamique, et si je la déclare dans la pile, sa création n'implique aucun temps pour l'allocation mémoire. Et cette classe dérivant d'une classe FixedString travaillant sur un char* avec une longueur maxi en paramètre, elle offre le même confort et le même contrôle qu'une classe String standard...avec gestion de la troncation automatique ou l'envoi d'exception par exemple...

Les tableaux de taille fixe sont autorisés dans les blocs Unsafe en C#.
J'admets que ce serait sympa de pouvoir faire une classe contenant ne serait-ce qu'un seul un tableau embedded (comme System.String) et que ça manque.

Le C++/CLI est malheureusement une aberration qui supprime l'héritage multiple pour l'adapter au .NET...donc n'est pas compatible avec C++

Euh... À ma connaissance, tu peux toujours utiliser l'héritage multiple dans les types non-managés...
Bien sûr, tu ne peux pas avoir le beurre et l'argent du beurre (héritage multiple dans un type managé).

[_skip]

toute struct crée ne sera pas dans la pile mais dans le tas...et donc leur allocation sera plus lente.

Il faut savoir que la *machine virtuelle* réserve des chunks importants de mémoire qu'elle utilise et recycle pour l'allocation des objets. Et ce fait un new en C# est pas comme un new en C++ au niveau de la réservation et du coût en performance.

La surcharge d'opérateur est un gadget en C# étant donné le peu d'opérateurs possibles...en particulier ne sont pas autorisé les opérateurs d'affectation, d'affectation, opérateurs logique, etc...

Aller, un bref tour d'horizon de ce que tu peux redéfinir

+, -, *, /, %, &, |, <<, >>
+, -, !, ~, ++, --
+=, -=, *=, /=, %=
==, !=, <, >, <= , >=

Tu ne peux pas surcharger ceux-ci :
&&, ||, ()

Franchement je trouve que c'est déjà mal, maintenant je suis encore jamais tomber sur une situation ou il m'aurait été confortable de pouvoir surcharger les opérateurs && et || .

L'utilisation d'un garbage non déterministe, le manque de contrôle sur l'allocation mémoire et la gestion des ressources, le niveau d'abstraction insuffisant...ceci explique pourquoi le C# n'est pas utilisé sur des projets avec de fortes contraintes sur les performances et les ressources tel que les moteurs 3D ou la programmation temps réel...et ne le sera certainement jamais...

Il y a déjà un ou deux trolls de 200 pages sur le sujet dans le forum débats, je te laisse aller lire.

[MenshaKaine]

Il faut savoir que la *machine virtuelle* réserve des chunks importants de mémoire qu'elle utilise et recycle pour l'allocation des objets. Et ce fait un new en C# est pas comme un new en C++ au niveau de la réservation et du coût en performance.

si c'est comme en java, ca peut devenir limitatif.

sinon coté c++/cli, je ne trouve pas ca pertinent, si c 'est pour faire du .net autant utiliser c# qui est un très beau langage qui offre plein de possibilité quasiment aussi souple que le c++.

Après je me demande si on est pas dépendant de l'évolution des assemblys du .net en c# sur la durée !?

[kurapix]

Ca fait un moment que ce sondage est sorti mais il est intéressant.

Pour ma part, je préfère le C ou C++ vu que j'aime cette sensation de contrôle et le low level.

Après à chaque projet ses besoins.

Un script shells en Python pour faire de l'administration de systèmes, du Java pour développer sous Android, du C ou C++ par habitude et par la base de code importante dans ces langages qui est disponible, ASM pour de la recherche et autres.

kurapix