Recommended usage of std::unique_ptr

Mushy picture Mushy · Mar 18, 2013 · Viewed 25.5k times · Source

What are recommended uses of a std::unique_ptr as to specifically where, when, and how is it is best used?

I discovered:

About unique_ptr performances

I already know:

  1. std::unique_ptr was developed in C++11 as a replacement for std::auto_ptr
  2. That a std::unique_ptr has no reference counting and "owns" object it points to
  3. There is no copy/assign with a std::unique_ptr
  4. When I need a unique pointer, std::unique_ptr is the go to structure

What I would like to know:

  1. Is using a std::unique_ptr ever preferable (other than uniqueness) to something
    else? What do I gain in this situation?
  2. If so, under what circumstances and when?
  3. Given the need for move semantics, would this make a std::unique_ptr less favorable
    overall?
  4. If a std::shared_ptr would suffice for dynamic memory management in nearly every situation, why does having at my disposal a std::unique_ptr matter (again, other
    than uniqueness)?

Answer

Kate Gregory picture Kate Gregory · Mar 18, 2013

In theory, you should use unique_ptr for all pointers unless you know you want to share it, in which case you should use shared_ptr. The reason is that unique_ptr has less overhead since it doesn't count references.

However, a unique_ptr is movable but not copyable, so using one as a member variable can require you to write more code (eg a move constructor), passing one by value means you'll need to use std::move and so on. As a result some people use shared_ptr out of laziness, because it's just easier, and the perf difference may not be significant for their app.

Finally a raw pointer is fine for observation - pointer uses that can never affect lifetime. Careful choice of the right pointer type can give those who read your code a good understanding of what you are doing. For more, see Herb Sutter's essay, Elements of C++ Style, specifically the "no delete" section.