Dovremmo passare un shared_ptr per riferimento o per valore?

Quando una funzione prende un shared_ptr(da boost o C ++ 11 STL), la stai passando:

• per riferimento const: void foo(const shared_ptr<T>& p)

• o per valore void foo(shared_ptr<T> p):?

Preferirei il primo metodo perché sospetto che sarebbe più veloce. Ma ne vale davvero la pena o ci sono altri problemi?

Potresti per favore fornire i motivi della tua scelta o, nel caso, perché pensi che non abbia importanza.

Questa domanda è stata discussa e risposta da Scott, Andrei ed Herb durante la sessione Ask Us Anything a C ++ e Beyond 2011 . Guarda da 4:34 su shared_ptrprestazioni e correttezza .

In breve, non vi è alcun motivo per passare per valore, a meno che l'obiettivo non sia condividere la proprietà di un oggetto (ad es. Tra diverse strutture di dati o tra thread diversi).

A meno che non sia possibile spostarlo, ottimizzarlo come spiegato da Scott Meyers nel video di talk collegato sopra, ma che è correlato alla versione effettiva di C ++ che è possibile utilizzare.

Un importante aggiornamento di questa discussione è avvenuto durante il pannello interattivo della conferenza GoingNative 2012 : Ask Us Anything! che vale la pena guardare, soprattutto dalle 22:50 .

Ecco la versione di Herb Sutter

Linea guida: non passare un puntatore intelligente come parametro di funzione a meno che non si desideri utilizzare o manipolare il puntatore intelligente stesso, ad esempio per condividere o trasferire la proprietà.

Linea guida: esprimere che una funzione memorizzerà e condividerà la proprietà di un oggetto heap utilizzando un parametro condiviso_ptr per valore.

Linea guida: utilizzare un parametro_ptr non const & solo per modificare shared_ptr. Usa const const_ptr & come parametro solo se non sei sicuro di prendere o meno una copia e condividere la proprietà; altrimenti usa invece il widget * (o, se non è nullable, un widget &).

Personalmente userei un constriferimento. Non è necessario incrementare il conteggio dei riferimenti solo per ridurlo di nuovo a causa di una chiamata di funzione.

Passa per constriferimento, è più veloce. Se è necessario conservarlo, dire in un contenitore, il rif. il conteggio verrà incrementato automaticamente magicamente dall'operazione di copia.

Ho eseguito il codice qui sotto, una volta con fooprendendo il shared_ptrby const&e ancora con il fooprendendo shared_ptrdal valore.

void foo(const std::shared_ptr<int>& p)
{
    static int x = 0;
    *p = ++x;
}

int main()
{
    auto p = std::make_shared<int>();
    auto start = clock();
    for (int i = 0; i < 10000000; ++i)
    {
        foo(p);
    }    
    std::cout << "Took " << clock() - start << " ms" << std::endl;
}

Usando VS2015, build di rilascio x86, sul mio processore Intel Core 2 Quad (2,4 GHz)

const shared_ptr&     - 10ms  
shared_ptr            - 281ms 

La copia per versione del valore era un ordine di grandezza più lento.
Se stai chiamando una funzione in modo sincrono dal thread corrente, preferisci la const&versione.

Dal C ++ 11 dovresti prenderlo per valore su const e più spesso di quanto potresti pensare.

Se stai prendendo lo std :: shared_ptr (piuttosto che il tipo T sottostante), allora lo stai facendo perché vuoi farci qualcosa.

Se vuoi copiarlo da qualche parte, ha più senso prenderlo per copia e std :: spostalo internamente, piuttosto che prenderlo da const e poi copiarlo. Questo perché si consente al chiamante la possibilità di attivare a sua volta std :: move shared_ptr quando si chiama la propria funzione, salvando così una serie di operazioni di incremento e decremento. O no. Cioè, il chiamante della funzione può decidere se ha bisogno o meno dello std :: shared_ptr dopo aver chiamato la funzione e in base al fatto che si sposti o meno. Ciò non è realizzabile se si passa da const &, quindi è preferibile prenderlo per valore.

Ovviamente, se il chiamante ha bisogno del suo shared_ptr in giro più a lungo (quindi non può std :: spostarlo) e non si desidera creare una copia semplice nella funzione (dire che si desidera un puntatore debole o che a volte si desidera per copiarlo, a seconda di alcune condizioni), quindi una const e potrebbe essere ancora preferibile.

Ad esempio, dovresti farlo

void enqueue(std::shared<T> t) m_internal_queue.enqueue(std::move(t));

al di sopra di

void enqueue(std::shared<T> const& t) m_internal_queue.enqueue(t);

Perché in questo caso crei sempre una copia internamente

Non conoscendo il costo del tempo dell'operazione di copia shared_copy in cui sono presenti l'incremento e il decremento atomico, ho sofferto di un problema di utilizzo della CPU molto più elevato. Non mi sarei mai aspettato che l'incremento e il decremento atomico potessero richiedere così tanti costi.

Dopo il risultato del test, l'incremento e il decremento atomici int32 impiegano 2 o 40 volte rispetto all'incremento e al decremento non atomici. L'ho preso su Core i7 3GHz con Windows 8.1. Il primo risultato viene fuori quando non si verifica alcuna contesa, il secondo quando si verifica un'alta possibilità di contesa. Tengo presente che le operazioni atomiche sono alla fine blocco basato su hardware. Lock is lock. Cattivo rendimento quando si verifica contesa.

Sperimentando questo, uso sempre byref (const shared_ptr &) che byval (shared_ptr).

C'è stato un recente post sul blog: https://medium.com/@vgasparyan1995/pass-by-value-vs-pass-by-reference-to-const-c-f8944171e3ce

Quindi la risposta a questa domanda è: non (quasi) mai passare const shared_ptr<T>&.
Basta semplicemente passare la classe sottostante.

Fondamentalmente gli unici tipi di parametri ragionevoli sono:

• shared_ptr<T> - Modifica e diventa proprietario
• shared_ptr<const T> - Non modificare, diventa proprietario
• T& - Modifica, nessuna proprietà
• const T& - Non modificare, nessuna proprietà
• T - Non modificare, nessuna proprietà, economico da copiare

Come sottolineato da @accel in https://stackoverflow.com/a/26197326/1930508, il consiglio di Herb Sutter è:

Usa const const_ptr & come parametro solo se non sei sicuro di prendere o meno una copia e condividere la proprietà

Ma in quanti casi non sei sicuro? Quindi questa è una situazione rara

È noto il problema che il passaggio di shared_ptr in base al valore ha un costo e, se possibile, dovrebbe essere evitato.

Il costo del passaggio di shared_ptr

La maggior parte del tempo che passa shared_ptr per riferimento, e ancora meglio per riferimento const, lo farebbe.

La linea guida di base cpp ha una regola specifica per il passaggio di shared_ptr

R.34: Prendi un parametro shared_ptr per esprimere che una funzione è il proprietario della parte

void share(shared_ptr<widget>);            // share -- "will" retain refcount

Un esempio di quando il passaggio di shared_ptr in base al valore è veramente necessario è quando il chiamante passa un oggetto condiviso a un chiamante asincrono, ovvero il chiamante esce dall'ambito prima che il chiamante completi il ​​suo lavoro. Il chiamato deve "prolungare" la durata dell'oggetto condiviso prendendo un valore share_ptr. In questo caso, passare un riferimento a shared_ptr non lo farà.

Lo stesso vale per il passaggio di un oggetto condiviso a un thread di lavoro.

shared_ptr non è abbastanza grande, né il suo costruttore \ distruttore fa abbastanza lavoro perché ci sia abbastanza overhead dalla copia per occuparsi delle prestazioni pass by reference vs pass by copy.