Discussion :

[bafman]

depuis quelques temps, je me suis mis à utiliser les smart_ptr de boost (bien ). 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 ).
Le truc, c'est qu'en lisant la doc, je suis tombé sur ca :

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 ), 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 , en bref, pour moi, le choix n'est vraiment pas obvious pour reprendre le terme de la doc de boost )

[loufoque]

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

[Médinoc]

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

[corrector]

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

Pourquoi?

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

[corrector]

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!

[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 est plus performant et peut être réobtenu à partir d'un pointeur nu, shared_ptr est compatible avec weak_ptr.

[corrector]

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

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

[corrector]

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.

[corrector]

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

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

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[corrector]

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.

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

[corrector]

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

[Matthieu Brucher]

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

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

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.

[corrector]

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

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?

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

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.

[corrector]

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

Où ça?

[corrector]

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?