Discussion :

[HanLee]

Bonjour,

Ce sujet m'intéresse car je me pose justement pas mal de question en ce moment sur l'avenir de ce qui reste mon langage de prédilection... J'ai une petite question par rapport à ceci :

En revanche le C++ ne comportera toujours pas de bibliothèque graphique standard, mais pourrait disposer d'un garbage collector

J'ai beau réfléchir je ne vois pas en quoi un garbage collector serait utile au C++. Avec les pointeurs intelligents le C++ atteindra un niveau de fiabilité quant à l'acquisition/libération de ressources qui sera le même que Java ou C#, sans pour autant s'encombrer d'un garbage collector lent et à destruction non-déterministe... A partir de là, quelqu'un peut-il éclairer ma lanterne sur la valeur ajoutée d'une telle chose ??

De mon point de vue, le garbage collector est surtout cette chose maudite qui m'empêche d'implémenter l'idiome RAII quand je fais du Java ou du C#, car il ne détruit pas les objets au moment même où on sort de leur contexte d'utilisation... alors l'idée de le retrouver en C++ ne m'enchante guère

Les shared_ptr sont plus lents qu'un garbage collector en pratique. Et garbage collector n'implique pas la lenteur non plus.

Et je ne vois pas pourquoi ça ne t'enchante pas parce que c'est évident qu'on ne va pas imposer un GC, et s'il y en a il sera optionnel, ou avec librairie, ou extension du langage je sais pas.

[:Bronsky:]

Hmm OK je me suis sûrement fait peur pour rien. Je fais trop le rapprochement entre l'utilisation d'un GC et certaines particularité de langages qui l'utilisent. J'ai cru qu'on allait se retrouver comme en java sans variables automatiques, à allouer dynamiquement tout et n'importe quoi, mais il n'y a pas de raison que ça se passe comme ça en effet. Et Stroustrup précise bien que le GC sera optionnel... reste à voir sous quelle forme ça se présentera.

[Aurelien.Regat-Barrel]

Il ne faut pas confondre la destruction de l'objet au sens exécution du destructeur et occupation de la mémoire. Un GC n'empêche pas la destruction déterministe (voir le C++/CLI). En C++ natif, la mémoire est libérée après l'exécution du destructeur. Avec un GC, la mémoire peut être libérée plus tard, et même déplacée en cours d'utilisation, afin de réduire la fragmentation, ce qui fait qu'un GC a tendance à devenir plus performant que les shared-ptr au fil du temps d'exécution et du nombre d'allocation/libération.

[Kaktus]

bronsky : Dans le livre "Pour mieux développer avec C++" , l'auteur dit que dans la prochaine norme il y AURAIT un GC mais qu'il serait optionnel et surtout désactivable à volonté. Bon ça date déjà mais ça rejoint ce que dit Aurélien .

Perso je n'y vois aucun inconvénient mais si cela se répercute sur la puissance du langage (qui est notre fer de lance) C++ perdra son intérêt et personne ne voudra de la nouvelle norme, c'est sûr.

Les GC ont encore bcp de progrès à faire, mais faisons leur confiance, je pense pas qu'on ait été déçu par les templates ou la STL

[outs]

Sans vouloir jouer l'ignorant, je n'ai jamais vu de document ou quoique que ce soit d'autre qui explique ce qu'est "la programmation par contrats".
En quoi cela consoiste-t-il ?

J'ai complété la page wikipedia sur la http://fr.wikipedia.org/wiki/Programmation_par_contrat c'est relativement syntétique si tu veux regarder. Y'a plein de liens vers des extensions pour les langages courant dans l'article anglais aussi.

Concernant l'avenir de C++, ben je vais être assez dur mais a mon avis C++ était un langage de transistion entre le C et la programmation objet. Mais maintenant que l'industrie c'est mis franchement à l'objet il n'y a plus trop d'avenir a C++ qui reste un peu usine a gaz vis à vis de langage exclusivement objet. Evidement reste une énorme base de logiciels écrit en C++ mais les utilisateurs fuient de tous les coté vers Java, C#, Objective C et autre pour ne citer que les langages très connu.

[Luc Hermitte]

Matthew Wilson a développé le sujet dans un article sur artima et dans son bouquin Imperfect C++. Contrairement à d'autres articles, je préfère les assertions pour détecter les erreurs de programmation. C'est parfois bien pratique un core.

Sinon, j'observe aussi que beaucoup fuient le C++ .. qu'ils ne connaissent vraiment pas. Et perso les langages typés "purs" objet, c'est un peu limité. Je n'aime pas le void* déguisé en Object.

[outs]

Le truc c'est que le système des assert peut être étendu pour rendre la programmation par contrat plus pratique. Par exemple pour avoir un affichage détaillé a l'exécution des erreurs. Ou pour pouvoir écrire des conditions sur l'ancienne valeur d'un variable. Pour pouvoir choisir quelle assertion on garde dans l'exécution : seulement les pre-condition, ou les post ou les invariant.

mais le gros problème est qu'il faut modifier le compilateur pour inclure une bonne gestion des contrat a l'exécution. Ce qui n'est pas évident en C++. alors en attendant un super support on peut en effet se limiter au mechanisme d'assert qui donne un résultat immédiat.

Sinon, j'observe aussi que beaucoup fuient le C++ .. qu'ils ne connaissent vraiment pas.

Le problème étant que le C++ est inutilement compliqué a cause de son héritage du C. Donc ce n'est pas étonnant que peu de monde soit capable de bien comprendre le C++. Déjà qu'il y a peu de monde capable de bien comprendre le C.

Et perso les langages typés "purs" objet, c'est un peu limité. Je n'aime pas le void* déguisé en Object.

La notion même de void* n'a plus de sens dans un langage objet pur. Par exemple moi j'aime beaucoup ce qu'ils font dans le langage eiffel, typé statiquement comme C++, compilation en code natif et efficace, template, héritage multiple et tout ce qu'il faut. Mais avec une syntaxe limpide. En plus le principale environnement de dev vient de passer en GPL.

En parlant de tout ça est-ce que dans la nouvelle version il est prévu que l'on puisse se servir des références dans *tous* les cas ou l'on utilisait des pointeurs ?
(je veux pas vous obliger a le faire, mais juste que je puisse le faire si j'ai envie)

[JolyLoic]

En parlant de tout ça est-ce que dans la nouvelle version il est prévu que l'on puisse se servir des références dans *tous* les cas ou l'on utilisait des pointeurs ?
(je veux pas vous obliger a le faire, mais juste que je puisse le faire si j'ai envie)

Assurément pas. Je pense par exemple à l'arithmétique de pointeurs, je ne vois pas les références pouvoir faire ça, même à très long terme.

Quel serait alors l'intérêt d'avoir les deux notions ?

[outs]

Assurément pas. Je pense par exemple à l'arithmétique de pointeurs, je ne vois pas les références pouvoir faire ça, même à très long terme.

Non on ne fera jamais d'arithmétique sur les références tout simplement parceque cela n'a pas de sens. Je me suis mal exprimé. En fait je pensais surtout au cas avec des classe abstraites, ou avec des templates ou on ne peut pas utiliser de références mais seulement des pointeurs. Alors que certains langages s'en sortent très bien avec les références dans ce cas (je parle pas de Java ...)

Quel serait alors l'intérêt d'avoir les deux notions ?

Ben compatibilité avec le code existant, faire de l'arithmétique sur pointeur pour ceux qui veulent.
Mais ils ont commencé a introduire les références, ca serai sympa de pousser le mécanisme jusqu'au bout. Ca serai un plus je pense.

[Aurelien.Regat-Barrel]

Java utilise en fait des pointeurs et non des références (une reference ne peut être nule).
En C++, tu as le principe des pointeurs intelligents qui immitent le principe de Java. C'est plus lourd à écrire, moins fiable, mais ça a quelques avantages. Y'a pas longtemps j'en ai fait une utilisation qui m'a quand même fait dire "Malgré tout ce qu'on dit, C++, c'est quand même super puissant".
En C++ on peut écrire du code plus simple à utiliser qu'en Java ou C#, grâce au RAII. Mais ça demande + de pratique qu'avec les autres langages.
Personnellement, je ne trouve pas que le langage en lui même est super complexe, ce sont les très nombreux concepts autour qui le rende obscure. Le C++ fait intervenir pas mal de génie logiciel je trouve.

[Jean-Marc.Bourguet]

Concernant l'avenir de C++, ben je vais être assez dur mais a mon avis C++ était un langage de transistion entre le C et la programmation objet. Mais maintenant que l'industrie c'est mis franchement à l'objet il n'y a plus trop d'avenir a C++ qui reste un peu usine a gaz vis à vis de langage exclusivement objet. Evidement reste une énorme base de logiciels écrit en C++ mais les utilisateurs fuient de tous les coté vers Java, C#, Objective C et autre pour ne citer que les langages très connu.

Je ne connais pas d'autres langages qui couvre tout les domaines d'applications que couvre le C++ (il y a Ada auquel il ne manque que la meta-programmation mais a un modele de concurrence depuis plus de 20 ans et de programmation repartie depuis plus de 10 ans -- et encore, Ada a ASIS --, mais je ne vois pas Ada progresser a mon grand regret d'ailleurs). Il n'est le meilleur dans aucun d'entre eux mais le seul a tout couvrir ce qui fait que c'est encore un bon choix.

Theoriquement, j'aime bien la purete dans un langage, tout rassemble sous quelques grands principes unificateurs... mais ca permet aussi de bien explorer les concepts... et d'en voir les limitations. Sincerement, faire comme en Effeil et devoir heriter d'une classe Math pour pouvoir ecrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

x = r*cos(theta); y = r*sin(theta);

je ne trouve pas ca tres limpide. Sans parler se mettre a passer 20 parametres supplementaires qui sont un etat mais parce qu'on fait du fonctionnel il faut les passer explicitement, ou alors se mettre a utiliser les monades... Il y a des choses qui ne se coulent pas facilement dans le moule objet, ou dans le moule fonctionnel, ou dans le moule declaratif, ou ... et dans le gene de programmes sur lesquels je travaille, c'est present. Donc en pratique j'aime bien les langages qui n'imposent pas une purete mais la permettent. Dans le genre type dynamiquement, il y a bien Oz (www.mozart-oz.org) mais en type statiquement, je n'ai encore rien vu de mieux qu'Ada et C++ n'est pas trop loin et a des avantages non techniques suffisemment importants pour que ce soit un bon choix.

[outs]

je ne vois pas Ada progresser a mon grand regret d'ailleurs).

Ouais mais l'extension objet a Ada le fait devenir une vrai usine a gaz. D'ailleur le créateur de Ada c'est retiré de l'affaire quand il a vu ce qu'il allait advenir de son langage. C'est d'autant plus dommage que c'était quelqu'un qui connaisait très bien le conception de langage objet. Mais a l'époque ce n'était pas la mode il a donc proposé une langage impératif pendant l'appel d'offre de création d'ADA.

Sincerement, faire comme en Effeil et devoir heriter d'une classe Math pour pouvoir ecrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

x = r*cos(theta); y = r*sin(theta);

Ce n'est plus le cas avec la nouvelle version d'EIffel, il y a un nouveau mécanisme pour faire ça. Ce n'est pas très différent d'utiliser un biblio math.h en C.

Sans parler se mettre a passer 20 parametres supplementaires qui sont un etat mais parce qu'on fait du fonctionnel il faut les passer explicitement, ou alors se mettre a utiliser les monades...

Oui c'est un problème de paradigme fonctionnel.

Il y a des choses qui ne se coulent pas facilement dans le moule objet, ou dans le moule fonctionnel, ou dans le moule declaratif, ou ... et dans le gene de programmes sur lesquels je travaille, c'est present.

C'est vrai c'est un problème. Mais perso je preferais trouver un moyen de faire collaborer 3 langages pur chacun spécialisé dans leur domaine plutot que d'avoir un grand langage fourre-tout et complexe qui devrat faire des concessions. Par exemple dans .Net on peut réutiliser du code d'un autre langage (bon ca merde un peu, mais l'idée est intéressante)

[Jean-Marc.Bourguet]

je ne vois pas Ada progresser a mon grand regret d'ailleurs).

Ouais mais l'extension objet a Ada le fait devenir une vrai usine a gaz. D'ailleur le créateur de Ada c'est retiré de l'affaire quand il a vu ce qu'il allait advenir de son langage. C'est d'autant plus dommage que c'était quelqu'un qui connaisait très bien le conception de langage objet. Mais a l'époque ce n'était pas la mode il a donc proposé une langage impératif pendant l'appel d'offre de création d'ADA.

Comment veux-tu etendre Ada83 avec de l'objet en faisant quelque chose qui n'est pas aussi complexe qu'Ada95? Car c'est bien la le probleme: la compatibilite est une contrainte forte en pratique et si c'est facile de faire mieux en n'en tenant pas compte, ca sort de cette contrainte. S'en abstraire est faire quelque chose de tres different.

Sincerement, faire comme en Effeil et devoir heriter d'une classe Math pour pouvoir ecrire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

x = r*cos(theta); y = r*sin(theta);

Ce n'est plus le cas avec la nouvelle version d'EIffel, il y a un nouveau mécanisme pour faire ça. Ce n'est pas très différent d'utiliser un biblio math.h en C.

Bonne nouvelle qu'il y ait des fonctions libres. Mais c'est aussi vraissemblablement -- je n'ai pas encore ete voir les details -- signe aussi un abandon du principe "tout est objet".

Il y a des choses qui ne se coulent pas facilement dans le moule objet, ou dans le moule fonctionnel, ou dans le moule declaratif, ou ... et dans le gene de programmes sur lesquels je travaille, c'est present.

C'est vrai c'est un problème. Mais perso je preferais trouver un moyen de faire collaborer 3 langages pur chacun spécialisé dans leur domaine plutot que d'avoir un grand langage fourre-tout et complexe qui devrat faire des concessions. Par exemple dans .Net on peut réutiliser du code d'un autre langage (bon ca merde un peu, mais l'idée est intéressante)

Ce que fait Oz est tres interessant car l'ensemble est tres prope de mon point de vue. Le seul probleme c'est que c'est un langage dynamiquement type.

[outs]

Bonne nouvelle qu'il y ait des fonctions libres. Mais c'est aussi vraissemblablement -- je n'ai pas encore ete voir les details -- signe aussi un abandon du principe "tout est objet".

Loupé il n'existe pas pour autant de fonctions libres. Et le principe tout est objet est respecté. C'est juste qu'un objet représente aussi une bibliothèque. Le principe de base d'eiffel est la fusion entre la notion de type et de biblitohèque.

Ce que fait Oz est tres interessant car l'ensemble est tres prope de mon point de vue. Le seul probleme c'est que c'est un langage dynamiquement type.

A mon avis c'est lié, c'est plus facile de proposer des choses comme une compilation native ou un typage statique si le langage est pur. Faire un compilo/verificateur de type sur un langage multi-paradigme est infernal. Je ne connait que Ocaml qui y arrive, mais il faut voir la tête de la syntaxe impérative, c'est en rupture avec l'usage courant.

[Jean-Marc.Bourguet]

Bonne nouvelle qu'il y ait des fonctions libres. Mais c'est aussi vraissemblablement -- je n'ai pas encore ete voir les details -- signe aussi un abandon du principe "tout est objet".

Loupé il n'existe pas pour autant de fonctions libres. Et le principe tout est objet est respecté. C'est juste qu'un objet représente aussi une bibliothèque. Le principe de base d'eiffel est la fusion entre la notion de type et de biblitohèque.

Ca me fait peur... je n'ai qu'un marteau, donc il n'y a que des clous... :-)

Ce que fait Oz est tres interessant car l'ensemble est tres prope de mon point de vue. Le seul probleme c'est que c'est un langage dynamiquement type.

A mon avis c'est lié, c'est plus facile de proposer des choses comme une compilation native ou un typage statique si le langage est pur.

Pour la compilation native, je ne vois pas tellement en quoi la purete intervient. D'ailleurs j'ai du mal a voir exactement ce qu'est la purete (j'ai depasse un peu quand meme la caricature que j'en ai fait ci-dessus). La typage dynamique, oui c'est un obstacle. Mais il y a des techniques connues qui rendent la chose quand meme possible ou les compilateurs Lisp auraient de gros problemes.

Le typage statique, c'est possible. Une definition de purete pouvant etre: dont le systeme de type est minimal, il est plus facile a definir (statique ou dynamique) etant minimal et coherent que s'il est complexe et remplit de cas particulier. Mais a part ca, si on a un systeme avec un typage dynamique, en faire un avec un typage statique se reduit a ajouter des annotations (ou eventuellement des regles d'inference, mais je l'accorde facilement c'est un peu plus complique) qui permette de determiner statiquement ce qui est valable (tout en sachant bien que tout ce qui etait valable ne va pas necessairement le rester).

[outs]

Ca me fait peur... je n'ai qu'un marteau, donc il n'y a que des clous... :-)

Ce n'est pas justifié. Les bibliothèques C++ (du style SDL, qt, par contre pas les bibliothque provenant du C) ont la même forme que celle d'eiffel. Tu pense vraiment qu'ils procedent différement que ce dont tu a l'habitude ?

De plus Eiffel possède un moyen simple pour réutiliser les lib C.

Pour la compilation native, je ne vois pas tellement en quoi la purete intervient. D'ailleurs j'ai du mal a voir exactement ce qu'est la purete

Oui c'est pas un très bon terme, je voulais juste dire que c'est plus simple de faire un compilo performant quand le langage ne part pas dans tous les sens (impératif + modules + objet + fonctionnel genre Ada ou Ocaml). Or un langage multiparadigme risque fort d'être beaucoup plus compliqué niveau grammaire. En plus il y a souvent un lien entre le typage et les optimisations possible par le compilo, car plus le compilateur connait de chose plus il peut prendre des décisions.

[Matthieu Brucher]

SDL, c'est plutôt du C que du C++.

[outs]

SDL, c'est plutôt du C que du C++.

Exact il fallait lire STL. merci

[Jean-Marc.Bourguet]

(J'aurais juré avoir déjà répondu...)

Ca me fait peur... je n'ai qu'un marteau, donc il n'y a que des clous... :-)

Ce n'est pas justifié. Les bibliothèques C++ (du style SDL, qt, par contre pas les bibliothque provenant du C) ont la même forme que celle d'eiffel. Tu pense vraiment qu'ils procedent différement que ce dont tu a l'habitude?

Il y a au moins une habitude que j'ai qu'une approche "intégriste" n'a pas: c'est d'utiliser le concept adapté au problème plutôt que d'adapter le problème aux concepts que j'accepte d'utiliser. Il me semble que la fonction libre est le concept adapté pour des fonctions comme cosinus (en tout cas, on ne m'a pas encore fourni le moindre argument du pourquoi ce ne le serait pas). Devoir en faire un membre d'une classe, c'est adapter le problème aux concepts.

Pour la compilation native, je ne vois pas tellement en quoi la purete intervient. D'ailleurs j'ai du mal a voir exactement ce qu'est la purete

Oui c'est pas un très bon terme, je voulais juste dire que c'est plus simple de faire un compilo performant quand le langage ne part pas dans tous les sens (impératif + modules + objet + fonctionnel genre Ada ou Ocaml).

Tu peux enlever performant. Il est plus simple de faire un compilo pour un langage simple qu'un langage compliqué. Je l'admet sans problème. Mais je préfère que la complication soit dans le langage et le compilateur plutôt que dans mes programmes. Je préfère un langage qui me permette de m'exprimer clairement plutôt que de passer par des détours.

[outs]

(J'aurais juré avoir déjà répondu...)

Désolé de te décevoir mais encore une question et je m'en vais :
Donc pas d'espoir de voir un changement dans le systeme des référence de C++ dans la prochaine version ?
(c'était ma question principale)