¿Deberíamos pasar un shared_ptr por referencia o por valor?

Cuando una función toma un shared_ptr(de boost o C ++ 11 STL), lo está pasando:

• por referencia constante: void foo(const shared_ptr<T>& p)

• o por valor void foo(shared_ptr<T> p):?

Preferiría el primer método porque sospecho que sería más rápido. ¿Pero realmente vale la pena o hay problemas adicionales?

¿Podría dar los motivos de su elección o, en su caso, por qué cree que no importa?

Scott, Andrei y Herb han discutido y respondido esta pregunta durante la sesión Ask Us Anything en C ++ y más allá de 2011 . Mire a partir de las 4:34 sobre shared_ptrrendimiento y corrección .

En breve, no hay razón para pasar por valor, a menos que el objetivo sea compartir la propiedad de un objeto (por ejemplo, entre diferentes estructuras de datos o entre diferentes hilos).

A menos que pueda moverlo, optimizarlo como lo explica Scott Meyers en el video de conversación vinculado anteriormente, pero eso está relacionado con la versión real de C ++ que puede usar.

Se produjo una actualización importante de esta discusión durante el panel interactivo de la conferencia GoingNative 2012 : ¡Pregúntenos cualquier cosa! que vale la pena ver, especialmente a partir de las 22:50 .

Aquí está la toma de Herb Sutter

Pauta: no pase un puntero inteligente como parámetro de función a menos que desee usar o manipular el puntero inteligente en sí, como compartir o transferir la propiedad.

Pauta: Exprese que una función almacenará y compartirá la propiedad de un objeto de montón utilizando un parámetro de valor compartido shared_ptr.

Directriz: Use un parámetro shared_ptr & non-const solo para modificar shared_ptr. Use un const shared_ptr & como parámetro solo si no está seguro de si tomará una copia y compartirá la propiedad; de lo contrario, utilice el widget * en su lugar (o, si no es anulable, un widget &).

Personalmente, usaría una constreferencia. No es necesario incrementar el recuento de referencia solo para disminuirlo nuevamente en aras de una llamada de función.

Pase por constreferencia, es más rápido. Si necesita almacenarlo, digamos en algún contenedor, la ref. El conteo se incrementará automáticamente por la operación de copia.

Ejecuté el siguiente código, una vez footomando el shared_ptrby const&y otra vez footomando el shared_ptrby.

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, compilación de lanzamiento x86, en mi procesador Intel Core 2 quad (2.4GHz)

const shared_ptr&     - 10ms  
shared_ptr            - 281ms 

La versión de copia por valor fue un orden de magnitud más lenta.
Si está llamando a una función sincrónicamente desde el hilo actual, prefiera la const&versión.

Desde C ++ 11 deberías tomarlo por valor sobre const y con más frecuencia de lo que piensas.

Si está tomando std :: shared_ptr (en lugar del tipo T subyacente), lo está haciendo porque desea hacer algo con él.

Si desea copiarlo en algún lugar, tiene más sentido tomarlo por copia, y std :: moverlo internamente, en lugar de tomarlo por constante y luego copiarlo. Esto se debe a que le permite a la persona que llama la opción a su vez std :: mover el shared_ptr al llamar a su función, ahorrándose así un conjunto de operaciones de incremento y decremento. O no. Es decir, el llamador de la función puede decidir si necesita o no std :: shared_ptr después de llamar a la función, y dependiendo de si se mueve o no. Esto no se puede lograr si pasa por const &, por lo que es preferible tomarlo por valor.

Por supuesto, si la persona que llama necesita su shared_ptr durante más tiempo (por lo tanto, no puede std :: moverlo) y no desea crear una copia simple en la función (digamos que quiere un puntero débil, o solo a veces quiere copiarlo, dependiendo de alguna condición), entonces una constante y aún podría ser preferible.

Por ejemplo, deberías hacer

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

encima

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

Porque en este caso siempre creas una copia internamente

Sin saber el costo de tiempo de la operación de copia shared_copy donde está el incremento y decremento atómico, sufrí un problema de uso de CPU mucho mayor. Nunca esperé que el incremento y la disminución atómicos puedan tomar tanto costo.

Siguiendo el resultado de mi prueba, el incremento y decremento atómico int32 tarda 2 o 40 veces más que el incremento y decremento no atómico. Lo obtuve en 3GHz Core i7 con Windows 8.1. El primer resultado sale cuando no ocurre contención, el segundo cuando ocurre una alta posibilidad de contienda. Tengo en cuenta que las operaciones atómicas son, por fin, un bloqueo basado en hardware. Cerradura es cerradura. Malo para el rendimiento cuando se produce la contención.

Experimentando esto, siempre uso byref (const shared_ptr &) que byval (shared_ptr).

Hubo una publicación reciente en el blog: https://medium.com/@vgasparyan1995/pass-by-value-vs-pass-by-reference-to-const-c-f8944171e3ce

Entonces la respuesta a esto es: (casi) nunca pases de largo const shared_ptr<T>&.
Simplemente pasa la clase subyacente en su lugar.

Básicamente, los únicos tipos de parámetros razonables son:

• shared_ptr<T> - Modificar y tomar posesión
• shared_ptr<const T> - No modificar, tomar posesión
• T& - Modificar, sin propiedad
• const T& - No modificar, sin propiedad
• T - No modificar, sin propiedad, barato para copiar

Como señaló @accel en https://stackoverflow.com/a/26197326/1930508, el consejo de Herb Sutter es:

Use un const shared_ptr & como parámetro solo si no está seguro de si tomará o no una copia y compartirá la propiedad

¿Pero en cuántos casos no estás seguro? Entonces esta es una situación rara

Es conocido el problema de que pasar shared_ptr por valor tiene un costo y debe evitarse si es posible.

El costo de pasar por shared_ptr

La mayoría de las veces pasaría shared_ptr por referencia, e incluso mejor por referencia constante.

La directriz central de cpp tiene una regla específica para pasar shared_ptr

R.34: tome un parámetro shared_ptr para expresar que una función es propietaria de una parte

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

Un ejemplo de cuándo es realmente necesario pasar shared_ptr por valor es cuando la persona que llama pasa un objeto compartido a una persona que llama asincrónica, es decir, la persona que llama queda fuera de alcance antes de que la persona que llama complete su trabajo. La persona que llama debe "extender" la vida útil del objeto compartido tomando un share_ptr por valor. En este caso, pasar una referencia a shared_ptr no funcionará.

Lo mismo ocurre para pasar un objeto compartido a un hilo de trabajo.

shared_ptr no es lo suficientemente grande, ni su constructor \ destructor hace suficiente trabajo para que haya suficiente sobrecarga de la copia para preocuparse por el rendimiento de paso por referencia vs paso por copia.