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]

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?

[corrector]

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

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?

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

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

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

[corrector]

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

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.

[Matthieu Brucher]

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

[corrector]

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 :

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

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