shared_ptr: para qué se utiliza

Question

Utilizo mucho boost :: scoped_ptr en mi código y es genial, pero actualmente estoy trabajando con un software que usa shared_ptr por todas partes y me pregunto si me falta algo.

AFAIK a shared_ptr solo es útil si diferentes hilos van a acceder a los mismos datos y no sabes en qué orden van a terminar los hilos (con shared_ptr asegurando que el objeto exista hasta que el último hilo haya terminado con it).

¿Hay otros casos de uso?

Answer 1

Los hilos son irrelevantes aquí. Lo relevante es si es fácil especificar un punto en el que el objeto ya no se usa.

Suponga que varios objetos diferentes desean usar el mismo objeto. Puede ser un paquete de datos, o para entrada / salida, o algún objeto geométrico, o lo que sea. Desea que el objeto compartido se elimine después de que se hayan eliminado todos los objetos en uso, y no antes de un ciclo de reloj. En lugar de averiguar qué objeto propietario tendrá la vida útil más larga (y eso puede cambiar si cambia el programa, o tal vez a través de la interacción del usuario), puede usar un shared_ptr para forzar este comportamiento.

No importa si los objetos que usan están en el mismo hilo o en hilos diferentes. Los objetos pueden tener vidas impredecibles incluso si están todos en el mismo hilo.

Answer 2

  

AFAIK a shared_ptr solo es útil si   diferentes hilos van a ser   acceder a los mismos datos

Bueno, es para situaciones en las que varios propietarios poseen el mismo objeto señalado por el puntero inteligente. Pueden acceder a los punteros inteligentes desde diferentes hilos, y shared_ptr también se puede utilizar en esa área, pero ese no es el punto principal. Si el último propietario pierde su referencia al objeto señalado, el mecanismo shared_ptr elimina el objeto.

Puede usar un scoped_ptr si todo lo que quiere tener es un puntero que se elimina cuando queda el alcance en el que se creó (ya sea por excepciones, por un goto a un lugar afuera, o por flujo de control normal o algún otro mecanismo). Si lo usa así, no hay necesidad de cambiar a shared_ptr.

Answer 3

La diferencia entre scoped_ptr y shared_ptr (y auto_ptr) es principalmente la semántica de copia.

• scoped_ptr es para " La asignación de recursos es la inicialización " y no se puede copiar (no se puede compartir con otras instancias y la propiedad no se puede transferir)
• shared_ptr es para la recuperación automática de memoria cuando se comparte entre varias partes
• auto_ptr es copiable (y transfiere la propiedad cuando se asigna)

Answer 4

Otra diferencia importante entre shared_ptr y scoped_ptr es que solo shared_ptr funciona con weak_ptr. Los punteros débiles se usan para romper los ciclos de punteros compartidos, evitando así pérdidas de memoria, pero débil_ptr se puede usar para más que eso.

Los punteros compartidos y débiles se pueden usar para expresar la diferencia entre referencias propias y no propias. La propiedad inequívoca de los datos conduce a un diseño más limpio, por lo que, cuando sea posible, los objetos de datos deben ser propiedad de uno otro objeto a través de shared_ptr. Todas las demás referencias de larga duración a objetos de datos deben ser punteros débiles, expresando su no propiedad de los datos. Cada vez que los módulos no propietarios acceden a los datos, necesitan convertir el débil_ptr en un compartido_ptr, en cuyo punto pueden encontrar que el objeto de datos ya no existe. Sin embargo, si bien los módulos no propietarios acceden al objeto de datos, lo mantienen a través de shared_ptr transitorio, lo que garantiza un funcionamiento seguro incluso si el objeto propietario liberara los datos.

Answer 5

Como ya se respondió, shared_ptr trata sobre la propiedad compartida. Sin embargo, diría que la propiedad compartida generalmente es algo malo (existen excepciones, como el patrón de peso mosca) y es mejor identificar un propietario y poner un scoped_ptr allí.

Answer 6

Un shared_ptr es un tipo de puntero inteligente que cuenta las referencias. Si solo hay un propietario para el objeto (caso frecuente), entonces scoped_ptr es la solución correcta. Si el objeto se puede compartir entre varias partes del código, shared_ptr no permitirá que el objeto se destruya hasta que se hayan liberado todas las referencias.