intrusive_ptr: Perché non è fornita una classe base comune?

Question

boost::intrusive_ptr richiede intrusive_ptr_add_ref e intrusive_ptr_release da definire. Perché non è fornita una classe base che lo farà? C'è un esempio qui: http://lists.boost.org/Archives/boost/2004/06/66957.php, ma il poster dice "Non penso necessariamente che questa sia una buona idea". Perchè no?

Aggiornamento: Non penso che il fatto che questa classe possa essere usata impropriamente con l'ereditarietà multipla è una ragione sufficiente. Qualsiasi classe derivante da più classi base con il proprio conteggio di riferimento avrebbe lo stesso problema. Se questi conti vengono implementati tramite una classe base o no, non fa differenza.

Non penso che ci sia alcun problema con il multithreading; boost::shared_ptr offre il conteggio dei riferimenti atomici e anche questa classe.

Answer 1

Boost fornisce una struttura per questo. Può essere configurato sia per conteggio dei riferimenti thread-safe o filo-non sicuro:

#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 problema sarebbe con l'ereditarietà multipla. Se erediti da 2 oggetti che implementano questa base, hai 2 contatori per il tuo singolo oggetto ... e questo potrebbe causare il caos.

Così si avrebbe bisogno di fare le ptr_add e ptr_release metodi virtuali, in modo che la classe derivata può implementare un override per sincronizzare correttamente i contatori multipli in una sola volta ... Alcuni penalizzazione delle prestazioni qui, soprattutto perché la maggior parte delle volte che sarebbe essere completamente inutile (non ci sarebbe alcun override) perché è utile solo per l'ereditarietà multipla, dopo tutto.

E naturalmente in ambienti multi-threaded si potrebbero avere (per brevi periodi di tempo) contatori desincronizzati (il primo è stato incrementato ma il thread è stato interrotto prima che il secondo fosse) Non riesco a pensare a nessun problema causa, ma non è una situazione sensata.

Si aggiunge anche clutter alla classe, alcuni client potrebbero non aver bisogno del conteggio dei riferimenti dopo tutto (se creano l'oggetto nello stack).

penso che non sia una buona idea;)

Answer 3

E 'in modo da poter utilizzare intrusive_ptr con classi che già implementano aggiungere e rilascio.