estendere shared_ptr per ereditarietà

Question

Cosa c'è di male nel fare qualcosa del genere?

class myclass : public std::shared_ptr<myotherclass> { 
    // some code, an allocation is never done 
    std::string get_info() { 
      if(*this != nullptr) return "<info>" + (this->info * 3) + "</info>"; 
      else return ""; 
    } 
}; 

quando nessuna assegnazione è effettuata nella classe --- è solo per fornire alcune decorazioni come sopra?

Answer 1

In linea di massima è consentito derivare dalle classi STL, vedere here e here. Tuttavia, è necessario essere consapevoli del fatto che non si dovrebbe lavorare con un puntatore alla classe base, ad esempio uno std::shared_ptr<myotherclass>* in questo caso.

Quindi questo e loro varianti dovrebbe essere vietato:

std::shared_ptr<myotherclass>* ptr = new myclass(/* ... */); 

... ma ha accettato, che sembra un po 'sintetico.

Perché è vietato? Perché le classi STL non hanno un distruttore virtuale. Pertanto, quando si desidera che la classe allocata sia delete, la parte derivata rimane. Ciò a sua volta invoca undefined behaviour ed eventualmente crea una perdita di memoria, anche se non si dispone di alcune allocazioni nella classe derivata.

Per fare ciò, una possibilità è quella di ricavare privatamente da shared_ptr:

class myclass : private std::shared_ptr<myotherclass> {}; 
       ^^^^^^^ 

Questo però potrebbe portare a problemi con la compatibilità binaria, vedere i commenti a this answer.

Alla mano, anche se il primo è consentito, si può andare con meno soggetto a errori e sia per uso composizione, in cui si effettua la shared_ptr un membro di myclass ed esporre la funzionalità richiesta (con l'inconveniente che a volte hanno per esporre molto). Oppure puoi impostare una funzione autonoma che fa quello che vuoi ... Lo so che lo sapevi ;-)

Answer 2

Dal momento che non lo farai mai manualmente delete (e non dovresti mai manualmente, delete, che è piuttosto il punto di shared_ptr in primo luogo), i distruttori virtuali non sono davvero un problema.

Alcuni problemi di interoperabilità possono tuttavia presentarsi.

1. Ottieni la classe derivata solo quando ne crei istanze specifiche. Quando ottieni shared_ptr da un posto come get_shared_from_this, non includerà il tuo info.

2. I modelli di funzione sovraccaricati su shared_ptr<T> non vedranno l'ereditarietà. La classe derivata sembrerà improvvisamente straniera a funzioni casuali come std::static_pointer_cast.

Fortunatamente, la libreria standard C++ è piena di ganci di estensibilità ordinata.È possibile installare un deleter personalizzato in questo modo:

template< typename t > 
struct my_deleter 
    : std::default_delete<t> { 
    std::string info; 

    my_deleter(std::string in_info) 
     : info(std::move(in_info)) {} 
}; 

std::shared_pointer<foo> myfoo(new foo, my_deleter{ "it's a foo" }); 

e recuperare le informazioni con una funzione non membro:

template< typename t > 
std::string get_my_info(std::shared_ptr<t> ptr) { 
    my_deleter<t> * dp = std::get_deleter< my_deleter<t> >(ptr); 
    if (! dp) return {}; 
    return dp->info; 
} 

Questa non è una buona architettura di programma, dal momento che c'è solo deleter uno personalizzato slot per oggetto condiviso. Può fare in un pizzico, però.