intrusive_ptr: Pourquoi pas une classe de base commune fournie?

Question

boost::intrusive_ptr nécessite intrusive_ptr_add_ref et intrusive_ptr_release à définir. Pourquoi pas une classe de base prévu le fera? Il y a un exemple: http://lists.boost.org/ Archives / boost / 2004/06 / 66957.php , mais l'affiche dit: « Je ne pense pas nécessairement c'est une bonne idée. » Pourquoi pas?

Mise à jour: Je ne pense pas que le fait que cette classe pourrait être mal utilisé avec l'héritage multiple est assez de raison. Toute classe qui dérive de plusieurs classes de base avec leur propre compte de référence aurait la même question. Que ces refcounts sont mis en œuvre par une classe de base ou fait non pas de différence.

Je ne pense pas qu'il y ait un problème avec multithreading; boost::shared_ptr offres comptage de référence atomique et cette classe pourrait aussi.

Answer 1

Boost fournit une installation pour cela. Il peut être configuré soit pour refcounting thread-safe ou thread dangereux:

#include <boost/intrusive_ptr.hpp>
#include <boost/smart_ptr/intrusive_ref_counter.hpp>

class CMyClass
    : public boost::intrusive_ref_counter<
                               CMyClass,
                               boost::thread_unsafe_counter>
     ...

boost::intrusive_ptr<CMyClass> myPtr;

http://www.boost.org/doc/ libs / 1_62_0 / libs / smart_ptr / intrusive_ref_counter.html

Answer 2

Il est donc vous pouvez utiliser intrusive_ptr avec des classes qui mettent en œuvre déjà add et relâchez.

Answer 3

Le problème serait avec l'héritage multiple. Si vous héritez de 2 objets implémentant cette base, vous disposez de 2 compteurs pour votre seul objet ... et qui pourrait causer des ravages.

Ainsi, vous devez faire les méthodes de ptr_add et ptr_release classe virtuelle, de sorte que la dérivée peut mettre en œuvre une dérogation pour synchroniser correctement les multiples compteurs à la fois ... Certaines pénalité de performance ici, d'autant plus que la plupart du temps il serait complètement inutile (il n'y aurait pas override), car il est seulement utile pour l'héritage multiple après tout.

Et bien sûr, dans des environnements multi-thread vous pourriez avoir (pour de courtes périodes) de compteurs désynchronisés (la première a été augmentée, mais le fil a été interrompu avant la deuxième était) Je ne peux pas penser encore de problème, il peut causer , mais ce n'est pas une situation saine d'esprit.

Vous ajoutez également l'encombrement à la classe, certains clients peuvent ne pas avoir besoin de comptage de référence après tout (si elles créent l'objet sur la pile).

Je pense que ce n'est pas une bonne idée;)