Un GC, maintenant, sait gérer tout seul les cycles ; à contrario des pointeurs à comptage de référence, avec lesquels il faut s'aider de weak_ptr ou assimilé
Un GC par comptage de référence de base non plus ne sait pas gérer les cycle, et c'est aussi le cas d'autres algorithmes. On pourrait très bien ajouter cette fonctionnalité aux smart-pointers, mais vu leur cadre d'utilisation ce ne serait pas très utile.
Un GC ne finalise (comprendre: "détruit") pas l'objet pointé à contrario de tous les smart-pointers du C++.
Les smart pointer non-plus ne finalisent pas les objets, ils font comme le GC : quand un objet n'est plus référencé, ils le signalent au gestionnaire de mémoire qui va s'occuper de la libération.
Tous les smart pointers ne sont pas à comptage de référence. La veille définition, c'est qu'un pointeur non brut/nu est smart/intelligent. Ainsi std::auto_ptr est un smart-pointer, tout comme boost::scoped_ptr, ou std::unique_ptr. [J'ai un peu de mal à voir pourquoi ces pinaillages autour des compteurs du coup]
Tous les GC ne sont pas non-plus à comptage de référence, on ne parlait du compteur que pour illustrer le fait qu'il y a bien une enveloppe créé autour du pointeur.
Les *_ptr<> de boost (et de C++11) peuvent encapsuler autre chose que de la mémoire, et ça c'est classe: nous avons ainsi des scoped_guard. Un GC ? Même pas en rêve. Il ne connait que la mémoire.
La majorité des GC te permet de le faire. Quasiment tous les GC permettent de spécifier un "destructeur" pour les objets : une fonction à appeler sur l'objet avant de le libérer quand il n'est plus référencé.
Donc, la classe *_ptr correspond à l'enveloppe du GC, le pointeur stocké dedans correspond à l'objet managé, et le destructeur à le même rôle dans les deux cas.
Après je me souviens de discussions sur fclc++ ou clc++m où un avantage était prêté aux GC : le MT car ils n'utilisaient pas de compteurs atomiques.
C'est juste que tels qu'ils sont définis, l'implémentation des *_ptr rend difficile l'utilisation d'algorithme de GC autres que les algorithme on-time de type comptage de références.
Le problème est que vu que tous les objets ne sont pas managé et les références ne peuvent être trouvées par exploration des objets, on ne peut pas vraiment faire autrement que d'intercepter la création et libération des références.
[^] # Re: templates variadiques
Posté par beagf . En réponse à la dépêche Le standard C++0x a enfin été voté. Évalué à 2.
Un GC par comptage de référence de base non plus ne sait pas gérer les cycle, et c'est aussi le cas d'autres algorithmes. On pourrait très bien ajouter cette fonctionnalité aux smart-pointers, mais vu leur cadre d'utilisation ce ne serait pas très utile.
Les smart pointer non-plus ne finalisent pas les objets, ils font comme le GC : quand un objet n'est plus référencé, ils le signalent au gestionnaire de mémoire qui va s'occuper de la libération.
Tous les GC ne sont pas non-plus à comptage de référence, on ne parlait du compteur que pour illustrer le fait qu'il y a bien une enveloppe créé autour du pointeur.
La majorité des GC te permet de le faire. Quasiment tous les GC permettent de spécifier un "destructeur" pour les objets : une fonction à appeler sur l'objet avant de le libérer quand il n'est plus référencé.
Donc, la classe *_ptr correspond à l'enveloppe du GC, le pointeur stocké dedans correspond à l'objet managé, et le destructeur à le même rôle dans les deux cas.
C'est juste que tels qu'ils sont définis, l'implémentation des *_ptr rend difficile l'utilisation d'algorithme de GC autres que les algorithme on-time de type comptage de références.
Le problème est que vu que tous les objets ne sont pas managé et les références ne peuvent être trouvées par exploration des objets, on ne peut pas vraiment faire autrement que d'intercepter la création et libération des références.