Discussion :

[Klaim]

Cette discussion est issue de la discussion http://www.developpez.net/forums/d95...-multiple-cpp/

En outre ce n'est pas aussi évident que cela qu'un Garbage Collector soit inutile en C++[1]. A ma connaissance, la possibilité d'en intégrer un a été abordée et le point n'est pas tranché.

En fait il y a une claire intention d'en apporter un dans le standard suivant C++0x. Ils n'ont visiblement pas pu l'intégrer dans C++0x par manque de temps pour trouver une solution convenable mais il y a des spécifications dans la nouvelle norme pour établir les bases nécessaires à un garbage collector standard (voir http://en.wikipedia.org/wiki/C%2B%2B...mplementations ).

Cela dit, il y a des conditions prérequises pour inclure un garbage collector standard, sinon ça sera l'echec :
- il doit être totalement optionel (et non-inclus par défaut - ne serait-ce que par rétrocompatibilité);
- il doit pouvoir cohabiter avec du code non-garbage-collecté (je me demande si ça ne nécessite pas une isolation par module avant de pouvoir faire ça convenablement);

Donc a voir dans quelques années...

[Joel F]

la sémantique de valeur et la RAII suffisent amplement hein.
j'échange pas mon baril de RAII pour un GC et une gestion asynchrone des destructions d'objets ...

[koala01]

la sémantique de valeur et la RAII suffisent amplement hein.
j'échange pas mon baril de RAII pour un GC et une gestion asynchrone des destructions d'objets ...

J'aurais tendance à être du même avis, bien qu'en étant, peut être, un chouia moins "borné"...

Dans les langages pour lesquels un garbage collector a été prévu dés le départ (java en tête), il me semble plus que normal de lui faire confiance et de profiter de toutes ses possibilités.

Par contre, quand un langage existe depuis plusieurs décennies, avec tout l'historique de code que cela implique, et, surtout, avec les habitudes RAII (ou plutôt l'effet inverse, dommage que le terme n'existe pas ) que l'on martèle à longueur d'années, je ne vois absolument pas en quoi un GC apporterait quoi que ce soit, si ce n'est la "dé-responsabilisation" du programmeur et les problèmes liés au retard de libération des ressources "classiques" d'un GC...

[JolyLoic]

la sémantique de valeur et la RAII suffisent amplement hein.
j'échange pas mon baril de RAII pour un GC et une gestion asynchrone des destructions d'objets ...

Il ne s'agirait pas d'échanger, mais d'avoir les deux.

Pendant les discussions sur le GC en C++0x, les débats étaient parfois très houleux, avec en particulier les boosteurs qui y étaient très fortement opposés, et prêts à tout pour défendre plutôt les smart pointers.

Voici des arguments que j'ai retenu de ces discussions :
- Un GC en C++ serait additionnel aux techniques existantes, et non pas à la place
- Un GC n'est pas adapté à toutes les ressources (par exemple, un handle de fichier, en gros, tout ce qui est IDisposable en C#), mais il y a des ressources où la libération non déterministe n'est pas un problème (la mémoire, par exemple)
- Pour éviter qu'il soit utilisé là où il n'est pas approprié, et éviter tout un tas d'aspect complexes (résurrection...) il était prévu que ce GC n'ait pas de notion de finaliseur, mais la discussion n'était pas fermée au moment où le GC a été reporté.
- Afin d'éviter toute baisse de perf, le GC doit être totalement désactivable
- Si quelqu'un utilise deux bibliothèques, l'une supposant qu'un GC est présent et l'autre non, que doit faire l'utilisateur, n'est-ce pas hyper complexe ? Que se passe-t-il si le GC est désactivé ? Finalement, ne condamne-t-on pas les personnes écrivant des bibliothèques à ne pas pouvoir se baser sur ce GC ?
- Des personnes ont utilisé sur de nombreux projets un GC en C++, et estiment que ce GC s'est montré rentable. Entre autre, ça simplifiait le modèle du code, et évitait de devoir se poser des questions shared/weak.
- Des personnes ont utilisé un GC sur un gros programme C++ qui avait été écrit sans GC en tête, mais avait des fuites mémoires qui avaient déjà coûté très cher sans avoir toutes été localisées. Le GC a permis de passer immédiatement le programme en exploitation.
- La présence d'un GC sans finaliseur ne change pas le comportement visible d'un programme (sauf en terme de perfs, éventuellement dans le bon sens si le programme présente des fuites). Pourquoi s'en passer ?
- Un GC légèrement modifié (par exemple en mode debug) peut être un bon outil de détection de fuites.

[poukill]

Afin d'éviter toute baisse de perf, le GC doit être totalement désactivable

Indispensable à mon avis s'il devait y avoir un GC.
Il y a trop de projets C++ qui contiennent aussi du C, et qui doivent rester performants, parce que c'est une application industrielle.

[koala01]

Indispensable à mon avis s'il devait y avoir un GC.
Il y a trop de projets C++ qui contiennent aussi du C, et qui doivent rester performants, parce que c'est une application industrielle.

A la limite, je me demande dans quelle mesure il ne devrait même pas être désactivé par défaut et activable (pour tout ou partie du projet) "sur demande expresse" uniquement...

Cela entrerait quelque part mieux dans la philosophie du "vous pouvez décider de l'utiliser, mais pensez au cout que cela aura" si chère au C++.

De plus, cela évitera de devoir revenir sur les options de compilation des projets qui ne posent pas problème / qui n'en ont pas besoin / qui souffriraient de son utilisation, et de décider *en connaissance de cause* de l'utiliser (en modifiant les options de compilation) sur les projets pour lesquels il présenterait un intérêt

Mais le jour où C++ devient totalement garbage collecté (sans possibilité de choisir de l'utiliser ou non), je change de langage

[poukill]

Je pense aussi qu'il ne faut pas de GC.
Le GC pourrait simplifier la vie des débutants c'est vrai. Mais le jour où ils tombent sur un vrai projet RAIIien, ils vont pleurer sévère.

Globalement, chaque langage a ses avantages / inconvénients.

• Langage orienté objet + GC ? -> Java, Python
• Langage orienté objet performant ? -> C++

Le C++ doit rester performant, c'est son cheval de bataille : performance et réutilisabilité, mais plus dur et long à coder.

C'est très grossier, mais globalement réaliste.

[gl]

j'échange pas mon baril de RAII pour un GC et une gestion asynchrone des destructions d'objets ...

S'il s'agit d'échanger les mécanismes actuels contre un GC, je te rejoins tout à fait.

Par contre s'il s'agit d'avoir un GC en complément des mécanismes actuels [1] qui soit en outre suffisamment flexible et contrôlable [2] (i.e. notament que l'on puisse désactiver voire mieux, comme le suggère Koala01, qui soit désactivé et que l'on puisse activer à la demande), je suis plutôt pour. Cela rajouterait un outil qui a certes des limitations et des contraintes mais également certains avantages, libre à chaque projet de l'utiliser ou non en fonction de ses besoins.



[1] En même temps, je n'imagine pas que cela puisse ne pas être le cas, ne serait-ce que pour la compatibilité.
[2] Et vu le résumé de Loïc, les discussions semblent bien aller dans ce sens.

[gl]

Le C++ doit rester performant, c'est son cheval de bataille : performance et réutilisabilité, mais plus dur et long à coder.

Mais un GC n'est pas forcément synonyme de mauvaises performances.

[Joel F]

j'attends *le* type de projet/design dans lequel le GC ne PEUT pas etre rempalcer par une approche classique.

[gl]

j'attends *le* type de projet/design dans lequel le GC ne PEUT pas etre rempalcer par une approche classique.

A priori aucun, il n'y a pas de projet que l'on ne puisse pas faire sans GC.

Par contre, le GC (ou tout du moins certains GC) permet de gérer certaines choses avec une quantité de travail moindre. Je pense par exemple à la défragmentation de la mémoire que réalise certains GC lors de la collecte de la mémoire, à faire sans GC c'est quand même pas trivial.

[3DArchi]

Mais un GC n'est pas forcément synonyme de mauvaises performances.

La gestion de la mémoire est synonyme de mauvaises performances.

[JolyLoic]

j'attends *le* type de projet/design dans lequel le GC ne PEUT pas etre rempalcer par une approche classique.

Je pourrai te le dire quand tu m'auras indiqué un projet dans lequel les smart pointers ne PEUVENT pas être remplacés par une gestion manuelle des ressources.

La question n'est pas pour moi est-ce que le GC est indispensable, mais plutôt est-ce qu'il y a des cas où il est plus utile/pratique que les alternatives actuelles (je pense que oui), et est-ce qu'il cohabite bien avec les alternatives actuelles (je ne me suis pas encore forgé une opinion).

La gestion de la mémoire est synonyme de mauvaises performances.

Mais si on va par là, on ne fait plus rien...

Le GC a des coût en performances qui sont différents de ceux d'une gestion par smart pointers, par exemple :

En mieux
- Aucune pénalité à la copie des pointeurs, même en environnement multithread
- Toute les désallocations mémoire peuvent avoir lieu dans un thread différent, et donc ne par ralentir le thread principal, alors qu'avec des smart pointers, le déterminisme qui n'est pas forcément utile impose une libération dans le thread de calcul lui même.

En moins bien
- Il y a plus de travail à faire pour savoir quoi libérer
- Comme la mémoire n'est pas libérée aussi vite, le programme peut être plus gourmand en mémoire (=> swap disque)

Le compactage de la mémoire, qui peut être un avantage des GC ne serait pas vraiment applicable à un GC en C++, donc je laisse de côté ce point.

[Joel F]

Je pourrai te le dire quand tu m'auras indiqué un projet dans lequel les smart pointers ne PEUVENT pas être remplacés par une gestion manuelle des ressources.

je reformule, un truc ou on regarde la chose et on se dit "ah bah oui sans GC je suis mort".

[JolyLoic]

Je pense qu'une gestion de graphe, potentiellement cyclique, où la représentation mémoire se fait à base de nœuds ayant des pointeurs sur les nœuds adjacents est un exemple où le GC est plus simple que les alternatives.

J'ai aussi un exemple dans du vrai code où l'on avait des conteneurs et des objets contenus, mais où l'objet contenu devait savoir par quoi il était contenu. Au début, on avait mis shared_ptr dans un sens, weak_ptr dans l'autre. Puis on s'était rendu compte que ce n'était pas bon, que c'était trop lourd, on a dû tout inverser, mais un point de détail avait mal été inversé, on avait donc des fuites mémoires. Avec un GC, on se serait posé moins de questions, et ça aurait marché du premier coup.

Maintenant, je n'ai pas d'expérience pratique de GC en C++ pour pouvoir dire si ça pose des problèmes ou pas (juste des témoignages de gens en qui j'ai assez confiance et qui en ont fait l'expérience).

[atttchoum]

- Des personnes ont utilisé un GC sur un gros programme C++ qui avait été écrit sans GC en tête, mais avait des fuites mémoires qui avaient déjà coûté très cher sans avoir toutes été localisées. Le GC a permis de passer immédiatement le programme en exploitation.

Effacement des fuites mémoires donc plus de problème ? Je n'en suis pas sûr.
C'est même l'exemple typique qui me fais penser que le GB n'est pas forcement une bonne chose.
Si je vois bien l'aspect pratique je trouve ça un peu dangereux.

[3DArchi]

Mais si on va par là, on ne fait plus rien...

Pas tout à fait. On localise bien temporellement là où on fait de la gestion mémoire pour être sur de ne pas consommer au mauvais moment.
Je ne suis pas très familier des GC mais j'ai cru comprendre qu'il pouvait y avoir plusieurs stratégies de 'récoltes' avec des arbitrages nécessaires entre le moment où ça a lieu pour perturber à minima les perfs et la disponibilité au moment où on a besoin de mémoire.
Probablement que dans beaucoup de cas un GC permet d'avoir une approche plus simple. Mais il y a des cas où on veut pouvoir 'tunner' au plus près. Et donc on a besoin d'une gestion mémoire manuelle.
Dans le fond, je ne pense pas que le GC soit bien ou mal. Mais il y a des moments où cela peut s'appliquer et d'autre pas. Et il faut garder ce choix.

[koala01]

Effacement des fuites mémoires donc plus de problème ? Je n'en suis pas sûr.

Une chose est sure: si, pour une raison ou une autre, tu es confronté à des fuites mémoires, il est préférable de déléguer la gestion de la mémoire à "quelque chose" (le GC) qui s'en occupera correctement, même si parfois avec du retard (par rapport à ce que tu aurais fais toi-même en évitant les fuites mémoires) que de les laisser trainer.

Cela ne résoudra sans doute pas tous les problèmes, mais cela en résoudra néanmoins un de taille et profitera, au moins à un certain niveau, à la qualité générale de l'application.

Cela ne veut absolument pas dire que je sois en faveur du passage à un C++ entièrement garbage collecté, très loin de là..

Je veux, simplement, mettre en évidence le fait que tout n'est jamais tout noir ni tout blanc, et que nous nous baladons encore une fois au travers d'une multitude de gris: comme beaucoup de choses en programmation, le garbage collector peut apporter certains avantages dans certaines situations.

Ne jamais avoir été confronté à une situation dans laquelle il apporte plus d'avantages que d'inconvénients ne signifie absolument pas qu'il n'existe aucune situation de ce type

[Invité]

Le problème d'un GC en C++, c'est que ca serait comme en D, un GC qui ne compacte pas et donc ne fait rien contre la fragmentation. Hors le problème de la gestion manuelle de la mémoire ce n'est pas vraiment les fuites mais la fragmentation.

Perso en D j'évite de l'utiliser hors initialisation (il n'est pas très efficace) et je préfère les pools / buffer circulaires.

[Invité]

je reformule, un truc ou on regarde la chose et on se dit "ah bah oui sans GC je suis mort".

Il me semble que la plupart des langages fonctionnels ont un GC pour permettre les closures sans se soucier du détenteur de l'environnement.