Svantaggi di shared_ptr

Question

Con shared_ptr incluso in C++ 11, si potrebbe ottenere un ambiente semi-garbage-collected. L'uso (inflazionistico?) Presenta alcuni svantaggi?

Potrei immaginare un modello di classe, in cui si crea una classe in cui si digita la classe alla fine come shared_ptr per abbreviare la sintassi.

///////////////// 
//// MyClass //// 
///////////////// 

#include <memory> 

class MyClass { 
public: 
    Myclass(); 
}; 

typedef std::shared_ptr<MyClass> SharedMyClass; 

/////////////////////// 
//// Example Class //// 
/////////////////////// 

class Example { 
public: 
    Example(): myClassObject(new MyClass()) {} 
private: 
    SharedMyClass myClassObject; 
}; 

Answer 1

Naturalmente ci sono degli svantaggi: si richiede memoria aggiuntiva per mantenere un conteggio di riferimento, e ogni volta che si copia o distruggere un'istanza shared_ptr questo conteggio di riferimento deve essere incrementato e decrementato. Se il programma utilizza più thread, la manipolazione del conteggio dei riferimenti deve essere eseguita in modo thread-safe, che può aggiungere un sovraccarico aggiuntivo, la cui entità dipende dall'implementazione.

Indipendentemente dal fatto che questo sovraccarico abbia un impatto negativo o negativo sul programma in base ai dettagli del programma. Generalmente si dovrebbe usare solo std::shared_ptr per le risorse che devono essere veramente condivise, perché può essere in qualche modo arbitrario su quale oggetto avrà bisogno di durare. In altri casi, un singolo punto di controllo è solitamente più facile da mantenere perché si sa esattamente per quanto tempo ciascuna risorsa sarà viva.

Inoltre, è necessario essere consapevoli del fatto che std::shared_ptr non è una panacea per la gestione della durata dell'oggetto. In particolare, se si dispone di due oggetti ciascuno dei quali è uno std::shared_ptr all'altro, gli oggetti hanno proprietà ciclica e non verranno mai eliminati automaticamente a meno che non si interrompa il ciclo invocando reset() su uno di essi.

Answer 2

Un'altra cosa che vale la pena menzionare è che è necessario fare molta attenzione quando si progettano le API con std::shared_ptr.

L'ovvio vantaggio rispetto a un puntatore raw è la gestione automatica della memoria (con il possesso ciclico della proprietà) ma rimangono altri problemi/domande. Quando la risorsa è condivisa, stai abbandonando (in una certa misura) il controllo e la capacità di ragionare sul tuo codice.

Posso modificare l'oggetto dato che non potrei essere l'unico a trattenerlo?

Si modifica l'oggetto e la modifica si riflette sull'intero sistema. Più grande è il sistema, meno evidenti sono le implicazioni ed è più difficile dimostrare che è effettivamente sicuro. Sean Parent dice spesso che un ptr condiviso è in effetti buono come una variabile globale.

Answer 3

I prestazioni sono importanti I wold non utilizzare std :: sahred_ptr. Ad esempio, per ordinare un array può con puntatori reali è 5 volte più veloce di ordinare con i puntatori condivisi.

D'altra parte il puntatore condiviso non evita tutti i problemi con perdite di dati inutili in caso di riferimenti circolari. Naturalmente, questo può essere risolto con weak_ptr, ma ciò che intendo è che anche quel puntatore condiviso deve essere gestito con cura.

Preferisco usare shared_ptr per elementi statici, perché gli elementi statici non vengono cancellati da un distruttore di una classe.