smart_ptr : shared vs intrusive

depuis quelques temps, je me suis mis à utiliser les smart_ptr de boost (bien :lol:). jusqu'à présent, j'ai toujours utilisé les shared_ptr car c'était les seuls pour lequels j'avais trouvé des exemples d'utilisation. Et puis, dernierement, j'ai decouvert l'existence des intrusive_ptr (ou plutôt, j'ai enfin compris comment ils fonctionnaient :oops:).
Le truc, c'est qu'en lisant la doc, je suis tombé sur ca :

Citation:

---

As a general rule, if it isn't obvious whether intrusive_ptr better fits your needs than shared_ptr, try a shared_ptr-based design first.

---

mais pourquoi donc ?
certe, l'utilisation des intrusive_ptr obligent à avoir un ref count et des fonctions en plus, mais du coup, on a plus besoin d'heriter de enable_shared_from_this quand on veut passer un pointeur this à un autre objet.
Le plus gros problème que je voit à cette approche est l'augmentation de la taille de la classe, ce qui n'est pas forcement idéale dans le cas de petites classes (mais alors vraiment très petite :roll:), et d'ailleurs, cet aventage est perdu si je doit heriter de enable_shared_from_this...

bref, le sujet du jour est :
- les shared_ptr c'est naze ?
- les intrusive_ptr c'est le mal ?
les pour et les contres (car la, j'ai vraiment du mal a choisir, et je ne sait pas si il faut que je passe au intrusive_ptr dans mon projet actuel, sachant que j'ai de plus en plus de classes qui heritent de enable_shared_from_this et que ca commence a franchement me fatiguer :aie:, en bref, pour moi, le choix n'est vraiment pas obvious pour reprendre le terme de la doc de boost :?)

A priori intrusive_ptr a aussi l'avantage qu'il peut être plus performant dans un environnement multi-threadé.

Je pense que l'intéret des shared_ptr<> sur les intrusive_ptr<> est d'éviter de trop modifier la classe pointée...

Citation:

---

Envoyé par loufoque

A priori intrusive_ptr a aussi l'avantage qu'il peut être plus performant dans un environnement multi-threadé.

---

Pourquoi?

intrusive_ptr est adapté quand on sait au moment où l'on design la classe que toutes les instance de la classe seront gérées sous forme de pointeur avec comptage de référence. C'est en général loin d'être la cas, c'est souvent plutôt l'utilisateur de la classe qui prend ce genre de décisions, pas son concepteur.

Citation:

---

Envoyé par JolyLoic

intrusive_ptr est adapté quand on sait au moment où l'on design la classe que toutes les instance de la classe seront gérées sous forme de pointeur avec comptage de référence. C'est en général loin d'être la cas, c'est souvent plutôt l'utilisateur de la classe qui prend ce genre de décisions, pas son concepteur.

---

Oui, mais quand le concepteur de la classe dérive de enable_shared_from_this, il prend déjà une décision de "supporter" le comptage de référence de shared_ptr. C'est déjà plus intrusif!

Effectivement, si on a enable_shared_from_this, on est déjà intrusif. Dans ce cas, je ne vois plus que 3 critères : intrusive_ptr est plus performant et peut être réobtenu à partir d'un pointeur nu, shared_ptr est compatible avec weak_ptr.

Citation:

---

Envoyé par JolyLoic

Effectivement, si on a enable_shared_from_this, on est déjà intrusif. Dans ce cas, je ne vois plus que 3 critères : intrusive_ptr [...] peut être réobtenu à partir d'un pointeur nu,

---

Heu... si on utilise enable_shared_from_this, c'est bien pour pouvoir obtenir un pointeur copropriétaire à partir d'un pointeur natif, non?

(En tout cas, c'est ce que fait l'exemple donné dans 20.6.6.4 Class template enable_shared_from_this [util.smartptr.enab].)

Pas tant que l'objet n'a pas été totalement construit et affecté à un shared_ptr. Alors qu'avec un comptage intrusif, ça doit pouvoir être bon même à ce moment là (non testé).

Citation:

---

Envoyé par JolyLoic

Pas tant que l'objet n'a pas été totalement construit et affecté à un shared_ptr. Alors qu'avec un comptage intrusif, ça doit pouvoir être bon même à ce moment là (non testé).

---

Par quelle magie? Si tu créé un pointeur possédant sur un objet, son compteur passe à 1. Si le pointeur venait à être détruit avant qu'un autre pointeur soit créé (et c'est bien le principe d'un pointeur copropriétaire qu'on le détruit quand on veut), le compteur repasse à 0, et l'objet est détruit (peut-être avant d'être fini de construire!).

boost::intrusive_ptr ne fait rien de plus que de manipuler un compteur via des fonctions libres.

Il me semble que ça avait été discuté dans fclc++ assez récemment, mais je n'ai pas réussi (et surtout j'ai la flemme) de le retrouver. La conclusion était qu'un tel intrusive_pointer devait avoir deux constructeurs (ou un flag), selon qu'il est construit dans le constructeur ou pas.

Ce qui équivaut (si je reconstitue tout bien dans ma tête, j'avais pas vraiment suivis le thread), à avoir un intrusive_ptr vers l'objet dans celui-ci, initialisé à this avant tous les autres intrusive_ptr (au début du ctor), et remis à 0 après la fin de la construction, une fois qu'un autre intrusive_ptr survivant au ctor a été initialisé. Un intrusive_ptr de survie, donc.

En espérant pas avoir écris des conneries.

Citation:

---

Envoyé par JolyLoic

Effectivement, si on a enable_shared_from_this, on est déjà intrusif. Dans ce cas, je ne vois plus que 3 critères : intrusive_ptr peut être réobtenu à partir d'un pointeur nu

---

Citation:

---

Envoyé par corrector

Si on utilise enable_shared_from_this, c'est bien pour pouvoir obtenir un pointeur copropriétaire à partir d'un pointeur natif, non?

---

Citation:

---

Envoyé par JolyLoic

Pas tant que l'objet n'a pas été totalement construit et affecté à un shared_ptr. Alors qu'avec un comptage intrusif, ça doit pouvoir être bon même à ce moment là (non testé).

---

Une conception intrusive (non testé) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

class C : public enable_shared_from_this<C> { public: C (shared_ptr<C>& p); private: void setup (); // part of construction }; void foo (shared_ptr<C>); void bar (C* p) { shared_ptr<C> sp = p->shared_from_this(); ... } void C::setup () { ... bar (this); } C::C (shared_ptr<C>& p) { p.reset (this); // DANGER ... foo (p); setup (); } // une factory pour cacher l'inélégance, et l'aspect inhabituel, de : // GROS problème d'exceptions ici NE PAS UTILISER shared_ptr<C> create_C () { shared_ptr<C> p; // construction par défaut : bof new C (p); // modification de p : bof bof return p; } int main() { shared_ptr<C> p = create_C (); // style fonctionnel : plus élégant }

---

EDIT : ajout de la factory create_C

ATTENTION! Il y a un gros problème d'exceptions avec ce code - ne pas utiliser tel quel.

Citation:

---

Envoyé par JolyLoic

shared_ptr est compatible avec weak_ptr.

---

Justement, quel est le problème, réel et courant, pour lequel la solution la plus simple et naturelle conduit à utiliser weak_ptr?

J'ai pas mal cherché un tel problème, mais je n'arrive pas à me l'imaginer.

Un graphe cyclique sur lequel on lâche la dernière référence externe au graphe. Sans weak_ptr, il n'est jamais libéré.

Citation:

---

Envoyé par Matthieu Brucher

Un graphe cyclique sur lequel on lâche la dernière référence externe au graphe. Sans weak_ptr, il n'est jamais libéré.

---

Je ne comprends absolument pas de quoi tu parles. Pourrais-tu me décrire le problème informatique spécifique à résoudre et sa solution C++ (ou le "squelette" de la solution si le code est trop long)?

Tu as un graphe de pointeurs, l'un pointant vers un autre, un cercle, quoi.
Si tu as un pointeur extérieur vers un pointeur appartenant au cercle et que tu le supprimes, tu t'attends à supprimer le cercle en entier. Si tu n'as pas de weak_ptr dans le cercle pointant vers ce même pointeur, ça ne marchera pas.

Je n'ai pas de code sous la main, et je n'ai pas non plus le temps d'en faire un juste pour ça ;) (mais la doc de weak_ptr en parle aussi...)

J'ai l'impression que Correcteur ne ne place pas sur le plan du codage, mais sur celui de la conception. Ce qui fait d'un exemple est encore plus long à construire...

J'ai remarqué qu'il existe des gens pour qui des objets existent indépendamment les uns des autres, ont leur propre vie, les liens de possession entre les objets étant complexes et variés. Pour ces gens, un weak_ptr est un complément indispensable à un shared_ptr.

Pour d'autres personnes, un objet existe principalement parce qu'il est dans un conteneur unique qui le possède, toute les autres références à cet objet pouvant alors se faire par pointeur nu. Pour ces gens, l'intérêt d'une weak_ptr (ou même d'un shared_ptr) est moins évident.

Citation:

---

Envoyé par JolyLoic

J'ai l'impression que Correcteur ne ne place pas sur le plan du codage, mais sur celui de la conception. Ce qui fait d'un exemple est encore plus long à construire...

---

Justement, plutôt qu'un exemple construit "spécialement pour moi", je préfèrerais savoir pour quoi vous utilisez weak_ptr dans vos programmes (si ce n'est pas indiscret).

Citation:

---

Envoyé par JolyLoic

J'ai remarqué qu'il existe des gens pour qui des objets existent indépendamment les uns des autres, ont leur propre vie, les liens de possession entre les objets étant complexes et variés. Pour ces gens, un weak_ptr est un complément indispensable à un shared_ptr.

---

Quel "lien de possession complexe" weak_ptr représente? ;)

Je peux te donner un exemple dans mon code au boulot, mais je n'ai bien évidemment pas le droit d'en dire trop, ce qui risque de limiter les discussions, en particulier sur les mérites comparés des design alternatifs...

Le principe de base était d'avoir pour l'utilisateur des objets dans des conteneurs, qu'il allait récupérer et manier comme bon lui semble. Par contre, pour des raisons d'optim, ces objets ne doivent pas exister en mémoire tant que l'utilisateur ne s'y intéresse pas, et doivent disparaître quand il ne s'y intéresse plus.

On a donc l'équivalent moral d'une map<string, weak_ptr<T> > et quand l'utilisateur tente d'accèder à un objet, soit le weak_ptr est vivant, et on retourne un shared_ptr issue de ce dernier, soit il ne l'est pas, dans ce cas là on le crée à la volée à partir d'un fichier de configuration. L'utilisateur n'a pas besoin de connaître ce mécanisme, il a récupérer ce shared_ptr, il le manipule et l'oublie sans se préocuper de cette gestion. Première utilisation.

De plus, notre objet T possède des sous objets U. Une partie de notre code manipule des shared_ptr<U> sans se préoccuper qu'ils font partie d'un T, donc il faut que de manière transparente, tant qu'un U est vivant, le T qui le contient soit vivant lui aussi. Notre U contient donc un shared_ptr<T> vers son père (il s'en sert aussi pour d'autres points). Si le T connaissait ses U sous forme de shared_ptr<U>, il y aurait référence circulaire, il les connaît donc sous forme de weak_ptr<U>. Seconde utilisation.

Citation:

---

Envoyé par Matthieu Brucher

(mais la doc de weak_ptr en parle aussi...)

---

Où ça?

Citation:

---

Envoyé par JolyLoic

J'ai l'impression que Correcteur ne ne place pas sur le plan du codage, mais sur celui de la conception.

---

Permettez-moi de reformuler ma question, de manière plus concise (ce week-end j'avais du mal à trouver mes mots).

Je me place du point de vue suivant :

Si weak_ptr est la réponse, quelle est la question?

Citation:

---

Envoyé par bafman

sachant que j'ai de plus en plus de classes qui heritent de enable_shared_from_this

---

Pourquoi tes classes doivent-elles hériter de enable_shared_from_this?

Autrement dit : quel est le contrat que tes classes garantissent, et qui nécessite enable_shared_from_this?

Citation:

---

Envoyé par JolyLoic

Je peux te donner un exemple dans mon code au boulot, mais je n'ai bien évidemment pas le droit d'en dire trop, ce qui risque de limiter les discussions, en particulier sur les mérites comparés des design alternatifs...

---

Je vais essayer de pas te faire perdre ton boulot alors. ;)

(Sauf que justement si je montre que ton design est sous-optimal, ça prouve mon point... :?)

Citation:

---

Envoyé par JolyLoic

Le principe de base était d'avoir pour l'utilisateur des objets dans des conteneurs, qu'il allait récupérer et manier comme bon lui semble. Par contre, pour des raisons d'optim, ces objets ne doivent pas exister en mémoire tant que l'utilisateur ne s'y intéresse pas, et doivent disparaître quand il ne s'y intéresse plus.

---

Dès qu'il ne s'y intéresse plus? Ce n'est donc pas tout à fait un cache (ma première idée a été : mais c'est un cache!).

Citation:

---

Envoyé par JolyLoic

On a donc l'équivalent moral d'une map<string, weak_ptr<T> > et quand l'utilisateur tente d'accèder à un objet, soit le weak_ptr est vivant, et on retourne un shared_ptr issue de ce dernier, soit il ne l'est pas, dans ce cas là on le crée à la volée à partir d'un fichier de configuration.

---

Donc quand la fonction cliente en a fini avec un T, elle détruit son shared_ptr<T>, le T est désalloué, mais il reste l'élément dans la map avec le weak_ptr<T> déconnecté ("null").

C'est voulu de garder cette trace de l'association en mémoire? Est-ce que cette association rompue comporte encore des informations utiles? Est-ce que cette entrée déconnectée va servir à optimiser la prochaine recherche du même objet, ou est-ce juste de la mémoire conservée inutilement?

(Tu me dis si je suis trop indiscret.)

Citation:

---

Envoyé par corrector

Donc quand la fonction cliente en a fini avec un T, elle détruit son shared_ptr<T>, le T est désalloué, mais il reste l'élément dans la map avec le weak_ptr<T> déconnecté ("null").

C'est voulu de garder cette trace de l'association en mémoire? Est-ce que cette association rompue comporte encore des informations utiles? Est-ce que cette entrée déconnectée va servir à optimiser la prochaine recherche du même objet, ou est-ce juste de la mémoire conservée inutilement?

---

Oui, c'est voulu. Ce qui est voulu, c'est qu'il reste une entrée dans la map portant le bon nom, que cette entrée est visible lors d'un parcours de la map, et que si l'utilisateur veut accéder à l'objet à nouveau, il le peut. Le déchargement dynamique est totalement transparent pour lui, il n'est même pas au courant qu'il existe.

Citation:

---

Envoyé par JolyLoic

Oui, c'est voulu. Ce qui est voulu, c'est qu'il reste une entrée dans la map portant le bon nom, que cette entrée est visible lors d'un parcours de la map, et que si l'utilisateur veut accéder à l'objet à nouveau, il le peut. Le déchargement dynamique est totalement transparent pour lui, il n'est même pas au courant qu'il existe.

---

Autrement dit, l'utilisateur n'a pas accès à la map.

Il a accès à quelquechose qui de son point de vue ressemble à une map<string, shared_ptr<T> >, mais en interne ressemble à une map<string, weak_ptr<T> > avec une instanciation automatique transparente à la demande.

Citation:

---

Envoyé par Matthieu Brucher

Tu as un graphe de pointeurs, l'un pointant vers un autre, un cercle, quoi.

---

Je comprends : x contient un shared_ptr vers y, y contient un shared_ptr vers x.

Autrement-dit x possède y, y possède x. Donc par transitivité x possède x! C'est absurde, quelque chose ne peut pas se posséder lui-même dans une gestion automatique des ressources.

Citation:

---

Envoyé par Matthieu Brucher

Si tu as un pointeur extérieur vers un pointeur appartenant au cercle et que tu le supprimes, tu t'attends à supprimer le cercle en entier.

---

Non, pas vraiment. Si une instance se possède elle-même, c'est en réalité qu'on fait de la gestion manuelle des ressources. Alors mieux vaut écrire "delete this;" que "me.reset();" (préférer ce qui est strait forward).

Dans le cadre d'une gestion automatique des ressources, basée sur des relations entre objets, relations matérialisées par des objets possédant (unique_ptr, shared_ptr, auto_ptr, etc.), relations correspondant au besoin effectif qu'a l'objet a d'avoir accès à l'objet b (a dépend de b, a possède b), l'auto-possession n'a aucun sens, elle est tautologique et triviale : tout objet a besoin de ses variables membre, introduire un objet possédant pour le matérialiser est absurde.

Citation:

---

Envoyé par Matthieu Brucher

Si tu n'as pas de weak_ptr dans le cercle pointant vers ce même pointeur, ça ne marchera pas.

---

Je ne comprends toujours pas ce que les weak_ptr vont y faire.

Supposons : j'ai mon graphe de pointeurs, l'un pointant vers un autre, un cercle, quoi. Je fais quoi, concrètement, en C++?

Citation:

---

Envoyé par bafman

Et puis, dernierement, j'ai decouvert l'existence des intrusive_ptr (ou plutôt, j'ai enfin compris comment ils fonctionnaient :oops:).

---

Comment tu as fais? Pas en lisant la doc je pense?

Tu peux nous expliquer ce que fait enable_shared_from_this, et en quoi c'est une bonne solution à quel problème?

Citation:

---

Envoyé par bafman

certe, l'utilisation des intrusive_ptr obligent à avoir un ref count et des fonctions en plus, mais du coup, on a plus besoin d'heriter de enable_shared_from_this quand on veut passer un pointeur this à un autre objet.
Le plus gros problème que je voit à cette approche est l'augmentation de la taille de la classe, ce qui n'est pas forcement idéale dans le cas de petites classes (mais alors vraiment très petite :roll:), et d'ailleurs, cet aventage est perdu si je doit heriter de enable_shared_from_this...

---

Avant de passer aux micro-optimisations, il faudrait préciser les contraintes imposées aux classes. (D'ailleurs, dans boost, enable_shared_from_this contient un weak_ptr qui contient deux pointeurs, donc c'est plus gros qu'un compteur de référence.)

Citation:

---

Envoyé par bafman

bref, le sujet du jour est :
- les shared_ptr c'est naze ?
- les intrusive_ptr c'est le mal ?

---

La question est mal posée, évidemment. Ce qu'il faut que tu décides, c'est si toutes les instances de ta classe doivent être allouées dynamiquement, et être gérées par un système de smart pointer donné. (Il faut penser en terme de besoins et pas de composants standards.)

Citation:

---

Envoyé par corrector

Je comprends : x contient un shared_ptr vers y, y contient un shared_ptr vers x.

Autrement-dit x possède y, y possède x. Donc par transitivité x possède x! C'est absurde, quelque chose ne peut pas se posséder lui-même dans une gestion automatique des ressources.

---

D'où l'intérêt des weak_ptr............

Toujours à propos de enable_shared_from_this, voici quelque chose de savoureux :

Citation:

---

Envoyé par N2315, 20.6.6.4/14 [util.smartptr.enab]

The shared_ptr constructors that create unique pointers can detect the presence of an enable_shared_from_this base and assign the newly created shared_ptr to its __weak_this member. —end note ]

---

Et comment pourrait-il le faire? La classe de base enable_shared_from_this peut être inaccessible ou bien ambigüe (ou les deux). Par définition, il n'est pas possible de tester si une classe de base est inaccessible ou ambigüe.

C'est pour cela qu'il vaut mieux toujours dériver de manière public de enable_shared_from_this.

Citation:

---

Envoyé par Matthieu Brucher

D'où l'intérêt des weak_ptr............

---

Justement, je ne vois pas. Voila exactement ce que je comprends :

Si on a graphe avec un cycle, et qu'on retire suffisamment d'arêtes, on peut obtenir un graphe sans cycle.

Comme ici on discute de C++, pas de théorie des graphes, et que le résultat ci-dessus est en plus assez trivial, je déduis que ce n'est pas ça que tu cherches à m'expliquer.

Quand tu me dis que weak_ptr suffit à résoudre le problème, tu pourrais aussi bien me dire qu'il suffit de voter pour le Parti de la Méditation Transcendantale (au fait, ils se présentent au municipales?) pour résoudre un problème de gestion de ressources en C++, ça me ferais le même effet : c'est possible qu'ils aient la solution au problème, mais je ne sais pas quelle est cette solution.

Le problème dont il est question ne peut pas être : comment éviter d'avoir "x contient un shared_ptr vers y, y contient un shared_ptr vers x". Pour ne pas avoir cette situation, il faut (et il suffit) de ne pas provoquer la situation où "x contient un shared_ptr vers y, y contient un shared_ptr vers x".

Chercher la solution de "x contient un shared_ptr vers y, y contient un shared_ptr vers x", c'est pour moi comme se demander si la phrase "La vache doit me touche de la jeudi" comporte une faute d'accord, où si tu préfère, comme poser la question : si x = 1/0, x \in R, quelle est valeur de x?

Il doit y avoir un problème de C++, qui doit être de la forme "comment faire quelque chose en C++", pas "pourquoi mon programme qui n'utilise pas weak_ptr ne marche pas?", ni "est-ce qu'un programme qui utilise weak_ptr peut ne pas avoir une caractéristique qu'a un programme "semblable" qui n'utilise pas weak_ptr?".

Citation:

---

Envoyé par Matthieu Brucher

C'est pour cela qu'il vaut mieux toujours dériver de manière public de enable_shared_from_this.

---

Si c'est requis quelque part, je ne l'ai pas vu. Si ça ne l'est pas, l'implémentation doit faire fonctionner :

Code:

---

1 2 3 4 5

class B; class A : enable_shared_from_this<B> {}; class B : A, enable_shared_from_this<B> {};   shared_ptr<B> p (new B);

---

Citation:

---

Envoyé par corrector

Justement, je ne vois pas. Voila exactement ce que je comprends :

Si on a graphe avec un cycle, et qu'on retire suffisamment d'arêtes, on peut obtenir un graphe sans cycle.

Comme ici on discute de C++, pas de théorie des graphes, et que le résultat ci-dessus est en plus assez trivial, je déduis que ce n'est pas ça que tu cherches à m'expliquer.

---

Le weak_ptr, ce sont les arêtes que tu supprimes, mais dont tu as tout de même besoin.
Si tu dois parcourir le graphe pour supprimer à la main les éléments, il te faudra un garbage collector, donc ça ne marche pas.

Est-ce que tu as regardé les liens donnés sur la page des smart_ptr ? En particulier celui-ci http://boost.org/libs/smart_ptr/smart_ptr.htm ?

Citation:

---

Envoyé par Matthieu Brucher

Est-ce que tu as regardé les liens donnés sur la page des smart_ptr ?

---

"la page des smart_ptr" => je ne vois de quelle page il s'agit

Citation:

---

Envoyé par Matthieu Brucher

En particulier celui-ci http://boost.org/libs/smart_ptr/smart_ptr.htm ?

---

Il y a pas mal de liens sur cette page. Je crois avoir parcouru les pages de boost sur les smart_ptr, mais j'ai pu manquer quelque chose. Peux-tu m'orienter sur la bonne page?

Tout en bas, les références, ils parlent des weak_ptr ;)

Citation:

---

Envoyé par Matthieu Brucher

Tout en bas, les références, ils parlent des weak_ptr ;)

---

Ceci : "[E&D-94] John R. Ellis & David L. Detlefs, Safe, Efficient Garbage Collection for C++, Usenix Proceedings, February, 1994. This paper includes an extensive discussion of weak pointers and an extensive bibliography"?

Bon, ça ne va parler de boost::weak_ptr (weak_ptr.hpp : (c) 2001, 2002, 2003 Peter Dimov), mais ça peut être intéressant.

Par rapport à boost :

Citation:

---

Envoyé par Safe, Efficient Garbage Collection for C++, 3.4. Smart pointers

In sum, smart pointers are actually rather dumb.

---

Assez ironique de la part de boost de citer ça.

Citation:

---

Envoyé par Safe, Efficient Garbage Collection for C++, 2.2. Coexistence

In particular, objects in the non-collected heap should be able to point at objects in the collected heap, and vice versa.
That is, a pointer of type T* should be able to reference an object of type T allocated in either heap.
[...]
These constraints preclude extensions to the type system identifying which pointers reference collected objects. Such extensions would require existing libraries to be modified and would effectively prevent libraries from manipulating both collected and non-collected objects.

---

Tout le contraire des "smart pointers", donc.

C'est passablement obsolète, par endroit :

Citation:

---

Envoyé par Safe, Efficient Garbage Collection for C++, 3.4. Smart pointers

Given class T derived from S, a smart pointer to T can't be assigned to a smart pointer to S.

---

(Les templates membres ne devaient pas exister à l'époque?)

Il est me semble t-il évident, bien que je ne le lise explicitement nul part, qu'on parle d'un gc pur jus, qui gère les cycles de pointeurs.

D'ailleurs, en cherchant "cycle", la première occurrence est :

Citation:

---

Envoyé par Safe, Efficient Garbage Collection for C++, 5.1. Object clean-up

If A and B have non-empty destructors and each is reachable from the other (that is, they form a cycle), neither will be cleaned up or collected.
[...]
In our design, cycles of objects with clean-up functions will never be collected or cleaned-up.

---

Donc à contrario, les cycles d'objets sans "clean-up functions" vont être collectés, c'est en tous cas ce que je comprends.

Donc le cas de pointeurs cycliques que tu décris est géré automatiquement par ce système, il n'y a aucun besoin d'utiliser des "weak pointers".