Pasar el ptr compartido de const y el ptr compartido como parámetro

En primer lugar, no pase un shared_ptr por una cadena de llamadas a menos que exista la posibilidad de que una de las funciones llamadas almacene una copia de ella. Pase una referencia al objeto referido, o un puntero raw a ese objeto, o posiblemente un cuadro, dependiendo de si puede ser opcional o no.

Pero cuando se pasa un shared_ptr, entonces preferiblemente pasarlo por referencia a const, porque copiar un shared_ptr tiene sobrecarga adicional. La copia debe actualizar el recuento de referencias compartidas, y esta actualización debe ser hilo seguro. Por lo tanto, hay un poco de ineficiencia que se puede evitar (de forma segura).

Respecto a

" el precio está haciendo que el código sea menos seguro, ¿verdad?

No. El precio es una indirecta extra en código máquina generado ingenuamente, pero el compilador lo maneja. Así que se trata de evitar una sobrecarga menor pero totalmente innecesaria que el compilador no puede optimizar para usted, a menos que sea súper inteligente.

Como David Schwarz ejemplificado en su respuesta, cuando pasa por referencia a const el problema de aliasing , donde la función que llama a su vez cambia o llama a una función que cambia el objeto original, es posible. Y según la ley de Murphy, sucederá en el momento más inconveniente, al máximo costo y con el código impenetrable más complicado. Pero esto es así independientemente de si el argumento es un string o un shared_ptr o lo que sea. Afortunadamente es un problema muy raro. Pero tenlo en cuenta, también para pasar instancias shared_ptr.

En primer lugar hay una diferencia semántica entre los dos: pasar el puntero compartido por valor indica que su función va a tomar su parte de la propiedad del objeto subyacente. Pasar shared_ptr como referencia const no indica ninguna intent además de simplemente pasar el objeto subyacente por referencia const (o puntero raw) aparte de forzar a los usuarios de esta función a usar shared_ptr. Así que en su mayoría basura.

Comparar las implicaciones de rendimiento de estos es irrelevante siempre y cuando son semánticamente diferentes.

De https://herbsutter.com/2013/06/05/gotw-91-solution-smart-pointer-parameters/

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

Y esta vez estoy totalmente de acuerdo con Herb:)

Y otra cita de la misma, que responde a la pregunta más directamente

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

Creo que es perfectamente razonable pasar por const & si la función de destino es sincrónica y solo hace uso del parámetro durante la ejecución, y no tiene más necesidad de él al regresar. Aquí es razonable ahorrar en el costo de aumentar el recuento de referencias, ya que realmente no necesita la seguridad adicional en estas circunstancias limitadas, siempre que comprenda las implicaciones y esté seguro de que el código es seguro.

Esto se opone a cuando la función necesita guardar el parámetro (por ejemplo, en un miembro de la clase) para una re-referencia posterior.

Si no hay ninguna modificación de la propiedad involucrada en su método, no hay beneficio para su método para tomar un shared_ptr por copia o por referencia const, contamina la API y potencialmente incurrir en sobrecarga (si pasa por copia)

La manera limpia es pasar el tipo subyacente por const ref o ref dependiendo de su caso de uso

void doSomething(const T& o) {}

auto s = std::make_shared<T>(...);
// ...
doSomething(*s);

El puntero subyacente no se puede liberar durante la llamada al método

Como se señala en C++ - shared_ptr: horrible velocidad, copiar un shared_ptr lleva tiempo. La construcción implica un incremento atómico y la destrucción un decremento atómico, una actualización atómica (ya sea incremento o decremento) puede evitar una serie de optimizaciones del compilador (las cargas de memoria / tiendas no pueden migrar a través de la operación) y a nivel de hardware implica el protocolo de coherencia de caché de CPU para garantizar que toda la línea de caché modificación.

Así que, tienes razón, std::shared_ptr<T> const& se puede usar como una mejora de rendimiento sobre solo std::shared_ptr<T>.

También tiene razón en que existe un riesgo teórico de que el puntero/referencia se cuelgue debido a algún aliasing.

Dicho esto, el riesgo ya está latente en cualquier programa C++: cualquier uso individual de un puntero o referencia es un riesgo. Yo diría que las pocas ocurrencias de std::shared_ptr<T> const& deben ser una caída en el agua en comparación con el número total de usos de T&, T const&, T*, ...

Por último, me gustaría señalar que pasar un shared_ptr<T> const& es raro. Los siguientes casos son comunes:

• shared_ptr<T>: Necesito una copia del shared_ptr
• T*/T const&/T&/T const&: Necesito un identificador (posiblemente nulo) para T

El siguiente caso es mucho menos común:

• shared_ptr<T>&: Puedo volver a colocar el shared_ptr

Pero pasando shared_ptr<T> const&? Los usos legítimos son muy, muy raros.

Pasando shared_ptr<T> const& donde todo lo que quieres es una referencia a T es un anti-patrón: obligas al usuario a usar shared_ptr cuando podrían asignar T de otra manera! La mayoría de las veces (99,99..% ), no debería importarle cómo se asigna T.

El único caso en el que pasaría un shared_ptr<T> const& es si no está seguro de si necesitará una copia o no, y porque ha perfilado el programa y demostrado que este incremento/decremento atómico era un cuello de botella, ha decidido aplazar la creación de la copia a sólo en los casos en que sea necesario.

Este es un caso tan extremo que cualquier uso de shared_ptr<T> const& debe ser visto con el más alto grado de sospecha.