Discussion :

[koala01]

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 et je préfère les pools / buffer circulaires.

Pas forcément...

Finalement, un GC n'est qu'une (partie d')application comme une autre, et toute application n'a que l'intelligence que l'on peut (ou que l'on veut) lui donner.

Encore faut-il que les différents intervenants susceptibles de prendre la décision de mettre un GC en place pour C++ puisse se mettre d'accord sur l'intelligence à donner à la bête... mais ce n'est pas une question de possibilité, juste une question de choix

[koala01]

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.

Il manque sans doute deux mots à la phrase de Joel: "en C++"

L'absence de GC dans les langages qui ont, dés leurs origines, été prévus pour fonctionner avec signifie, fatalement, la mort des programmeurs qui les utilisent en cas de retrait.

Il vaut mieux rester dans le cadre stricte de C++ pour essayer de répondre à sa question:

Y aurait-il un projet en C++ qui ne serait possible que grâce à la présence d'un GC A mon sens, la réponse est non

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

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

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

[yan]

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

Comme je le comprend, le RAII c'est aussi un problème de scope. I.e savoir quand finaliser la ressource.
Hors comme en C# toute classe est référence, son scope dépend du GC. Le using sert à spécifier un scope réduit.

En C++, c'est plus simple car en principe on ne faut pas de new sur une classe implémentant le RAII (non?).

Avoir un "GC + une classe allouée par new" posera le même problème qu'en C# : Quand doit elle être libérer?

[koala01]

En C++, c'est plus simple car en principe on ne faut pas de new sur une classe implémentant le RAII (non?).

Il n'y a pas grand chose à voir entre le RAII (ou le RFID) et l'utilisation ou non de la gestion dynamique de la mémoire...:
RAII au sens strict est une approche qui consiste à faire en sorte que tout objet créé soit directement placé dans un état cohérent avec son utilisation, sans qu'il soit besoin de faire "autre chose de plus"

RFID est l'approche qui consiste à faire en sorte que toute les ressources gérées par un objet soient correctement libérées et finalisées au moment de la destruction du dit objet.

La gestion dynamique de la mémoire a pour objectifs:

• de permettre la création d'un objet de type dérivé en le faisant passer pour son type de base (cas d'utilisation fréquent avec des objets polymorphes)
• de permettre à l'utilisateur de prendre le contrôle de la durée de vie de l'objet créé
• de permettre la persistance d'un objet en dehors de la portée dans laquelle il est construit (new dans une fonction + renvoi d'un pointeur)
• de permettre la destruction de l'objet dont l'utilisateur a pris le contrôle de la durée de vie lorsqu'il n'en a plus besoin (delete sur un pointeur pointant sur un objet alloué par new)

Au final, les deux premier (RAII et RFID) ne font que s'assurer que certains contrats seront remplis lors de la construction et de la destruction et la gestion dynamique de la mémoire n'est qu'une des possibilités qui nous sont offertes pour assurer la construction et la destruction d'un objet

Ce sont donc bel et bien deux aspects tout à fait transversaux

[yan]

RFID est l'approche qui consiste à faire en sorte que toute les ressources gérées par un objet soient correctement libérées et finalisées au moment de la destruction du dit objet.

C'est ce à quoi correspond IDisposable. Du moins la partie libération des ressources pour que l'objet est toujours détruit par le GC.

Ce sont donc bel et bien deux aspects tout à fait transversaux

pas pour moi. RAII ou RFID as du sens que s'il y as une gestion de la porté de la variable. Si on ne peut prévoir le moment de sa destruction, tous l'intérêt est perdu. Et autant parlé de constructeur/destructeur.
Tu imagine ouvrir un fichier et ne pas savoir quand il sera fermé?

Le c++ le permet grâce au scope des données ou de la destruction manuelle et C# grâce à using (c'est comme cela que je le comprend).
Java ne le permet pas car il n'as aucune équivalent. Tu devra donc faire un close et espérer ne pas avoir oublié une sortie de la fonction.

[Luc Hermitte]

Java ne le permet pas car il n'as aucune équivalent. Tu devra donc faire un close et espérer ne pas avoir oublié une sortie de la fonction.

Si. Java a le dispose/release-pattern, exactement comme le C# ou même le viml (si si)). A savoir : try+finally.
C'est juste que ce n'est pas un déterminisme implicite.

[yan]

Le GC pourrait simplifier la vie des débutants c'est vrai.

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.

C' est un peu ce que je reproche au GC. Ils sont trop souvent vue comme une simplification du problème. Perso, je trouve les GC très compliqué. A chaque fois j'ai l'impression d'avoir un code qui tombe en marche.... Surtout en JAVA.
Pour moi c'est pas pour un débutant. Quand on l'utilise il faut savoir pourquoi et comment l'utiliser correctement.

Pour un GC en C++, je dirais oui mais à une condition : l'importance du const. C'est ce qui me choque le plus en Java (et C#) c'est que tous est passé en référence sans aucun contrat de const et la variable passé en paramètre d'une fonction peut être modifier par n'importe ou....

[yan]

Si. Java a le dispose/release-pattern, exactement comme le C# ou même le viml (si si)). A savoir : try+finally.
C'est juste que ce n'est pas un déterminisme implicite.

ok. Je ne svais pas qu'il y avais le finally.

[koala01]

pas pour moi. RAII ou RFID as du sens que s'il y as une gestion de la porté de la variable. Si on ne peut prévoir le moment de sa destruction, tous l'intérêt est perdu. Et autant parlé de constructeur/destructeur.

Constructeur et destructeur ne sont que... le moyen de mettre RAII et RFID en oeuvre

Par contre, il faut faire la différence entre la portée des ressources utilisées par un objet et... la portée d'utilisation de l'objet.

Après tout, ce n'est pas pour rien si les termes agrégation et composition représentent deux concept qui, bien que fort proches sont malgré tout différents

Une chose est sure, c'est que, si un objet est responsable de la durée de vie d'un de ses membres, il faut bel et bien veiller à ce que ce membre soit correctement détruit et finalisé au moment où l'objet est détruit

[Jean-Marc.Bourguet]

C' est un peu ce que je reproche au GC. Ils sont trop souvent vue comme une simplification du problème. Perso, je trouve les GC très compliqué. A chaque fois j'ai l'impression d'avoir un code qui tombe en marche.... Surtout en JAVA.
Pour moi c'est pas pour un débutant. Quand on l'utilise il faut savoir pourquoi et comment l'utiliser correctement.

Je crois que le plus gros adversaires des GC, ce sont ses partisants qui les sur-vendent. Comme je l'ai déjà écrit, un GC n'est jamais qu'un mécanisme -- relativement facile à mettre en oeuvre tant qu'on n'a pas à l'implémenter soi-même -- pour mettre en place une politique de responsabilité partagée de la libération de la mémoire. Mais ça n'empèche pas qu'il faut choisir la politique de gestion de la mémoire et en implémenter non fournit par le GC (*). Entre autre, s'assurer que tous les pointeurs non possédant sont soit weak -- si la sémantique correspond -- soit n'ont une valeur que quand un pointeur possédant à la même.

Pour un GC en C++, je dirais oui mais à une condition : l'importance du const. C'est ce qui me choque le plus en Java (et C#) c'est que tous est passé en référence sans aucun contrat de const et la variable passé en paramètre d'une fonction peut être modifier par n'importe ou....

Je ne vois pas ce que tu crains. Si j'ai bonne mémoire, ce qui est nécessaire pour permettre un GC optionel en C++ c'est simplement interdire quelques manipulations qui permettent de cacher des pointeurs, ou plus précisément permettre d'annoter le code qui ne les fait pas pour indiquer qu'il est compatible avec un GC (certaines propositions ont 3 niveau: code incompatible, code compatible mais n'en ayant pas besoin, code ayant besoin d'un GC pour libérer la mémoire). Il y a aussi quelques aspects annexes (finalisation, weak pointeur, controle du moment où une phase de GC a lieu, ...)


En passant, il ne faut pas confondre la finalisation et la destruction. Les deux sont des choses différentes:
- la destruction, c'est le mécanisme qu'on connait bien en C++
- la finalisation, c'est ce que fournit un GC.

(*) Détecter des motifs qui correspondent à d'autres politiques -- par exemple celle des variables automatiques -- et courcicuiter alors le GC est d'ailleurs une optimisation faite par certains compilateurs de langages à GC. C'est remarquablement un motif par lui-même les langages plus "permissifs" (que ce soit sur ce point ou sur le typage) cherchant à obtenir les performances de langages plus explicites en répérant des motifs qui sont imposés ou du moins explicites dans ces derniers. L'inconvéniant de l'implicite est qu'il ne permet pas de faire la différence entre les cas où le motif plus efficace n'est pas respecté à cause d'une erreur de programmation et ceux où on profite de la souplesse supplémentaire. La question est de savoir si la souplesse supplémentaire compense le changement de certaines erreurs qui seraient détectables à la compilation en des erreurs de comportement. La réponse est à mon sens beaucoup plus nuancée et circonstantiées que certains -- dans les deux camps d'ailleurs -- le croient.

(**) La finalisation, c'est simplement un callback (ou un observeur, c'est à mon sens un peu plus simple de comprendre la finalisation en introduisant d'abord la possibilité d'avoir un observeur puis en remarquand que l'objet peut s'observer lui-même) appelé par le GC quand il remarque qu'il n'y a plus de référence vers cet objet. Ce callback peut entre autre réintroduire des nouvelles références (et potentiellement se réenregistrer pour un nouvel appel quand il n'y aura à nouveau plus de références). Il n'est jamais certain qu'un finaliseur sera appelé (mais dans ce cas là, les références weak ne sont pas remises à NULL non plus, savoir si elles le sont quand le finaliseur rend l'objet à nouveau accessible est un choix de conception du GC).

[yan]

@koala01 j'avais bien compris je voulais juste dire que quand je parle de RAII je pense aux pointeurs intelligents, std::vector, flux,... qui libèrent leurs ressources lors de leurs destruction à la sortie de leurs scope.

Je ne vois pas ce que tu crains.

De ne pas pouvoir savoir ou spécifier si une instance passée en paramètre d'une lib peut être modifier ou non par celle çi. J'ai peur qu'un GC en C++ va favoriser l'oublie du const pour se rapprocher de la sémantique de java et C# qui n'ont pas d'équivalent à ma connaissance (je me trompe peut être).