Should I use shared_ptr or unique_ptr?

dziwna picture dziwna · Feb 14, 2013 · Viewed 17k times · Source

I have a question about std::unique_ptr and std::shared_ptr. I know there are loads of questions about when to use which one, but I'm still not sure if I understand it correctly. I read somewhere that the default choice for smart pointer should be std::unique_ptr, but as I understand it, for my needs I should rather use std::shared_ptr. For example, I have:

class B;
class A
{
private:
   B* b;
public:
   B* getB();
};

A::getB()
{
   return b;
}

So basically class A owns pointer to object of type B and there's a method which returns this pointer. If I create getter, I assume that some other class can access this pointer and therefore it should be shared_ptr instead of unique_ptr. Am I right, or I don't get it yet?

Answer

Arne Mertz picture Arne Mertz · Feb 14, 2013

Short answer: depends.

It depends on if the pointer returned by getB may be stored/used somewhere while the owning A has gone out of scope. The difference is about ownership not about how many pointers you do have.

  • If the A still exists when you use the result of getB , you can store a unique_ptr and return a plain pointer (or a reference if getB can never return nullptr). That expresses "A owns B, and no-one else does".
  • If the A might go out of scope while you are using/holding the result of getB, but the B should go out of scope together with (or shortly after) the A, store a shared_ptr and return a weak_ptr.
  • If possibly many objects, including the callers of getB, may hold on to the B and there is no clear single owner, store and return shared_ptrs.