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.

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

[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

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

[Invité]

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

GC et RAII cohabitent sans problèmes...

[koala01]

GC et RAII cohabitent sans problèmes...

Tout dépend de ce que l'on appelle RAII...

Dans l'absolu, si l'on ne considère RAII par ce que signifie l'acronyme (Ressource Acquisition Is Initialization), sans s'inquiéter de l'effet contraire qui consiste à libérer les ressources à la destruction, l'un n'empêche strictement pas l'autre.

Par contre, si on considère que RAII est une "règle de vie" qui consiste aussi bien à initialiser les ressources à l'acquisition qu'à les libérer correctement à la destruction, l'aspect de gestion de ressources du GC devient... purement et simplement superflu.

Je ne prétendrai pas savoir mieux que Joêl ce qu'il voulait dire, mais je présume qu'il aborde RAII sous l'angle de la deuxième approche évoquée

[Joel F]

oui exactement.

mais +1 pr les closures en fonctionel

[Jean-Marc.Bourguet]

Un GC n'est jamais qu'un moyen d'implémenter une politique de gestion de la mémoire avec une responsabilité partagée de la libération. Demander où l'utilisation d'un GC est utile revient à demander où est utile l'utilisation d'une responsabilité partagée de la libération de la mémoire.

L'utilisation d'un GC permet une approche simple et systématique par rapport à l'alternative qui revient à déterminer statiquement quand la mémoire devient libérable (ou en pratique une borne supérieure). Il faut noter pour commencer qu'un GC aussi remplace il revient à remplacer la notion "la mémoire ne sera plus utilisée" (notion qui est utilisable parfois statiquement) par "il n'y a plus de référence vers la mémoire" et donc impose d'une part qu'on fasse disparaîre les références le plus tôt possible sous peine de délais ou de fuite de mémoire.

L'algorithme de GC le plus simple est le comptage de référence (et ses variantes par chaînage). Il a des avantages:
- implémentable directement en C++ sans changer le langage;
- libération à la disparition de la dernière référence.
Il a été utilisé comme GC dans des langages à GC (certaines implémentation de Lisp et d'Algol 68, les premières implémentation de Python si j'ai bonne mémoire).

J'ai l'impression que certains ne se demande pas si un GC est utile en C++ mais plutôt si le comptage de référence ne suffit pas. Il faut donc rappeler ses:
- utilisation de plus de mémoire (par objet ou par pointeur; mais les autres techniques de GC ont aussi leur overhead mémoire, souvent plus important; l'effet est principalement des perfs sur les caches),
- action à chaque assignation ou presque (ce qui cause un coût réparti qu'il est difficile d'évaluer),
- impossibilité de traiter les cycles sans action manuelle,
- difficulté de prédire l'état dans lequel la finalisation est appelée, ce qui peut poser des problèmes dans un environnement multithread (impossibilité de savoir s'il faut acquérir ou non un mutex -- la finalisation dans le cas d'autres techniques de GC est appelée dans une thread à part et on sait donc qu'il faut acquérir le mutex)

[white_tentacle]

GC et RAII cohabitent sans problèmes...

GC et RFID ?

Je ne connais pas de langages qui fassent cohabiter ça sans problème. IDisposable n'est pas une solution élégante, la méthode python qui consiste à ignorer les erreurs dans le destructeur me semble hasardeuse (même s'il semblerait que ça ne marche pas trop mal)...

Personnellement, la manière la plus élégante que je vois de les faire cohabiter est d'offrir plusieurs allocateurs au programmeur. Définir un gc_new, par exemple, et bien sûr des restrictions sur les objets allouables avec gc_new (comme par exemple, pas de destructeur non généré par le compilo, récursivement). Pas sûr que ça simplifie le langage, par contre...

[yan]

IDisposable n'est pas une solution élégante,

Pourquoi?
J'ai pas beaucoup d'expérience en C#, mais utiliser le using pour un scope sur une ressource me semblais pas si mal. C'est un bon compromis, non?

[JolyLoic]

Pourquoi?
J'ai pas beaucoup d'expérience en C#, mais utiliser le using pour un scope sur une ressource me semblais pas si mal. C'est un bon compromis, non?

Pas vraiment je trouve. Au lieu d'être spécifié une fois et une seule, lorsqu'on design la classe, c'est à chaque utilisation de celle-ci qu'il faut penser à mettre le using. Et si on oublie de le mettre le compilateur ne dit rien...

[Invité]

GC et RFID ?

Je ne connais pas de langages qui fassent cohabiter ça sans problème.

Tu veux dire RAII ?

En D tu as la storage class "scope" qui assure la destruction immédiate d'un objet en sortant de la portée courante. Cet objet échappe donc au GC et peut être placé sur la pile. Ca sert pour les ressources genre fichiers, locks...

Tu peux aussi supprimer explicitement un objet avec delete, faire un malloc qui echappe au GC, tu as une forme de placement new, tu peux ajouter et retirer des GC "roots"... au final le GC n'est pas vraiment un problème, tant qu'on s'en sert pas trop .

Par contre en Java, je n'ai jamais compris comment forcer un finalizer à s'exécuter.

EDIT: et +1 à Jean-Marc.Bourguet qui rappelle les problèmes du comptage de référence.

[Luc Hermitte]

Tu veux dire RAII ?

Resource Finalization is Destruction.

En fait, le terme RAII serait mal usité vu qu'il réfère à la construction, alors que c'est pour sa propriété lors de la destruction qu'il est si en vogue.