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