shared_ptr: what's it used for
Asked Answered
P

6

4

I make a lot of use of boost::scoped_ptr in my code and it is great but I'm currently working with software that uses shared_ptr all over the place and I'm wondering if I'm missing something.

AFAIK a shared_ptr is only useful if different threads are going to be accessing the same data and you don't know what order the threads are going to finish (with the shared_ptr ensuring that the object exists until the last thread has finished with it).

Are there other use cases?

Patras answered 5/12, 2008 at 14:49 Comment(0)
M
7

Threads are irrelevant here. What's relevant is whether it's easy to specify a point at which the object is no longer of use.

Suppose several different objects want to use the same object. It might be a pack of data, or for input/output, or some geometric object, or whatever. You want the shared object to be deleted after all of the using objects are deleted, and not a clock cycle before. Rather than figure out which owning object is going to have the longest lifespan (and that can change if you change the program, or perhaps through user interaction), you can use a shared_ptr to force this behavior.

It doesn't matter whether the using objects are in the same or different threads. Objects can have unpredictable lifetimes even if they're all in the same thread.

Mowbray answered 5/12, 2008 at 15:6 Comment(0)
R
7

AFAIK a shared_ptr is only useful if different threads are going to be accessing the same data

Well, it's for situations where multiple owners own the same object pointed to by the smart pointer. They may access the smart pointers from different threads, and shared_ptr is usable in that area too, but that's not the main point. If the last owner loses its reference to the object pointed to, the shared_ptr mechanism deletes the object.

You can use a scoped_ptr if all you want to have is a pointer that is deleted when the scope it's created in is left (either by exceptions, by a goto to a place outside, or by normal control flow or some other mechanism). If you use it like that, there is no need to change to shared_ptr.

Radiotransparent answered 5/12, 2008 at 14:54 Comment(0)
M
7

Threads are irrelevant here. What's relevant is whether it's easy to specify a point at which the object is no longer of use.

Suppose several different objects want to use the same object. It might be a pack of data, or for input/output, or some geometric object, or whatever. You want the shared object to be deleted after all of the using objects are deleted, and not a clock cycle before. Rather than figure out which owning object is going to have the longest lifespan (and that can change if you change the program, or perhaps through user interaction), you can use a shared_ptr to force this behavior.

It doesn't matter whether the using objects are in the same or different threads. Objects can have unpredictable lifetimes even if they're all in the same thread.

Mowbray answered 5/12, 2008 at 15:6 Comment(0)
C
2

The difference between scoped_ptr and shared_ptr (and auto_ptr) is mainly copy semantics.

  • scoped_ptr is for "Resource Allocation Is Initialization" and is not copyable (it cannot be shared with other instances and ownership cannot be transferred)
  • shared_ptr is for automatic reclamation of memory when shared between multiple parties
  • auto_ptr is copyable (and transfers ownership when assigned)
Cocci answered 18/4, 2009 at 3:58 Comment(0)
C
2

Another important difference between shared_ptr and scoped_ptr is that only shared_ptr work with weak_ptr. Weak pointers are used to break cycles of shared pointers, thereby avoiding memory leaks, but weak_ptr can be used for more than that.

Shared and weak pointers may be used to express the difference between owning and non-owning references. Unambiguous ownership of data leads to a cleaner design, so when possible data objects should be owned by one other object through a shared_ptr. All other long-lived references to data objects should be weak pointers, expressing their non-ownership of the data. Each time any non-owning modules access the data, they need to convert the weak_ptr into a shared_ptr, at which point they may find that the data object no longer exists. However, while the non-owning modules access the data object, they hold it through transient shared_ptr, ensuring safe operation even if the owning object were to release the data.

Cusped answered 19/7, 2011 at 1:26 Comment(0)
D
1

As answered already, shared_ptr is about shared ownership. However, I would argue that shared ownership is generally a bad thing (exceptions exists, such as flyweight pattern) and it is better to identify an owner and put a scoped_ptr there.

Desireah answered 5/12, 2008 at 17:54 Comment(0)
S
1

A shared_ptr is a smart pointer type that does reference counting. If there's only one owner for the object (frequent case), then scoped_ptr is the right solution. If the object can be shared among multiple parts of the code, then shared_ptr won't let the object be destructed until all references to it have been released.

Schizophyceous answered 30/4, 2009 at 5:25 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.