Devo passare da boost :: shared_ptr a std :: shared_ptr?

Vorrei abilitare il supporto per C ++ 0x in GCC con -std=c++0x . Non ho assolutamente bisogno di nessuna delle funzionalità C ++ 11 attualmente supportate in GCC 4.5 (e presto 4.6), ma mi piacerebbe iniziare ad abituarmi. Ad esempio, in alcuni punti in cui utilizzo gli iteratori, sarebbe utile un tipo auto .

Ma ancora una volta, non ho bisogno di nessuna delle funzionalità attualmente supportate. L’objective qui è di incoraggiarmi a incorporare le caratteristiche del nuovo standard nel mio “vocabolario” di programmazione.

Da quanto sai del supporto C ++ 11, è una buona idea abilitarlo in GCC, e poi abbracciarlo, ad esempio, passando da boost::shared_ptr a std::shared_ptr esclusivamente come i due don ‘ t mescolare?

PS: Sono a conoscenza di questa buona domanda che mette a confronto i diversi sapori di shared_ptr ma sto chiedendo un consiglio di livello superiore su cui utilizzare prima che lo standard sia finalizzato. Un altro modo per dirlo, quando un compilatore come GCC dice che supporta una “funzione sperimentale”, significa che probabilmente incontrerò degli strani errori durante la compilazione che saranno i principali sink temporali e una fonte di domande criptiche su StackOverflow?

Modifica : ho deciso di tornare da std::shared_ptr perché non mi fido del suo supporto in GCC 4.5 come mostrato dall’esempio in questa domanda .

Ci sono un paio di motivi per passare a std::shared_ptr :

  • Si rimuove una dipendenza da Boost.
  • Debugger. A seconda del compilatore e del debugger, il debugger potrebbe essere “intelligente” su std::shared_ptr e mostrare direttamente l’object puntato all’object, dove non lo direbbe, l’implementazione di boost. Almeno in Visual Studio, std::shared_ptr aspetto di un semplice puntatore nel debugger, mentre boost::shared_ptr espone un sacco di boost::shared_ptr di boost.
  • Altre nuove funzionalità definite nella domanda collegata.
  • Si ottiene un’implementazione che è quasi garantita essere la semantica del movimento abilitata, il che potrebbe far risparmiare alcune modifiche al conto. (Teoricamente – Non l’ho testato io stesso) A partire dal 2014-07-22, boost::shared_ptr capisce come spostare la semantica.
  • std::shared_ptr usa correttamente delete [] sui tipi di array, mentre boost::shared_ptr causa un comportamento indefinito in questi casi (devi usare shared_array o un deleter personalizzato) (In realtà sono corretto. Vedi questo : la specializzazione per questo è per unique_ptr only, not shared_ptr .)

E uno dei principali motivi evidenti per non:

  • Dovresti limitarti al compilatore C ++ 11 e alle implementazioni della libreria standard.

Alla fine, non devi davvero scegliere. (E se stai prendendo di mira una specifica serie di compilatori (es. MSVC e GCC), potresti facilmente estenderlo per usare std::tr1::shared_ptr quando disponibile.Sfortunatamente non sembra essere un modo standard per rilevare il supporto TR1 )

 #if __cplusplus > 199711L #include  namespace MyProject { using std::shared_ptr; } #else #include  namespace MyProject { using boost::shared_ptr; } #endif 

Suppongo che dipenda da quanto usi la spinta. Personalmente la uso solo molto raramente (in effetti la libreria di numeri casuali, in un singolo progetto). Recentemente ho iniziato a usare -std=c++0x per i miei altri progetti, e uso le nuove funzionalità di std :: library come shared_ptr in loro. Mi piace che i miei progetti abbiano il minimo di dipendenze, quindi preferirei dipendere dall’implementazione della libreria standard del compilatore piuttosto che dall’aumento.

Ma non penso che ci sia una risposta valida per tutti a questa domanda.

Dovresti sempre usare std::shared_ptr dove ansible, se è disponibile, invece di boost. Questo è fondamentalmente perché tutte le nuove interfacce che usano shared_ptr useranno lo standard condiviso ptr.

Probabilmente non è una ctriggers idea iniziare a prendere l’abitudine di usare std :: shared_ptr quando consentito dal compilatore. Poiché l’interfaccia è la stessa di shared_ptr di boost, puoi sempre tornare indietro se necessario.

Se stai semplicemente costruendo su una piattaforma che va bene (fai il cambio)
(Nota: hai dei test unitari per convalidare la retrocompatibilità, vero?)

Se compili su più piattaforms è dove diventa un po ‘più complicato in quanto devi convalidare che le funzionalità di g ++ 4.5 sono disponibili su tutte le piattaforms che usi (ad esempio, per Mac / Linux il compilatore predefinito per Mac g ++ è ancora un paio di la versione è dietro ai compilatori predefiniti su Linux).

Un’altra ragione per passare a std::shared_ptr : supporta std::unique_ptr , cioè ha costruttore.

boost::shared_ptr no.

A parte la consistenza dell’implementazione, boost::shared_ptr attualmente conserva almeno due vantaggi di nicchia rispetto a std::shared_ptr :

  • La disponibilità di boost::make_shared_noinit . È particolarmente utile in combinazione con gli array, evitando sia il costo di inizializzazione zero e il sovraccarico di allocazione separata. (FWIW, è anche una proposta di aggiunta allo standard).
  • Boost.Python fa un uso speciale del supporto boost::shared_ptr per i boost::shared_ptr personalizzati cancellati dal testo, ma non fa ancora lo stesso per std::shared_ptr .

Ho trovato std :: shared_ptr per essere più veloce di boost :: shared_ptr. Ho fatto un test, puoi rivedere il codice e vedere i risultati del grafico a torta confrontando i puntatori condivisi boost, Qt e std.

inserisci la descrizione dell'immagine qui

https: //www.osletek.com …