Recommended usage of std::unique_ptr
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.
Related videos on Youtube
Mushy
Updated on July 09, 2022Comments
-
Mushy almost 2 years
What are recommended uses of a
std::unique_ptr
as to specifically where, when, and how is it is best used?I discovered:
I already know:
-
std::unique_ptr
was developed in C++11 as a replacement forstd::auto_ptr
- That a
std::unique_ptr
has no reference counting and "owns" object it points to - There is no copy/assign with a
std::unique_ptr
- When I need a unique pointer,
std::unique_ptr
is the go to structure
What I would like to know:
- Is using a
std::unique_ptr
ever preferable (other than uniqueness) to something
else? What do I gain in this situation? - If so, under what circumstances and when?
- Given the need for move semantics, would this make a
std::unique_ptr
less favorable
overall? - If a
std::shared_ptr
would suffice for dynamic memory management in nearly every situation, why does having at my disposal astd::unique_ptr
matter (again, other
than uniqueness)?
-
Stephane Rolland about 11 yearssince the type is called
unique_ptr
, I find it strange you're searching for other use than being unique... -
rubenvb about 11 years
-
rubenvb about 11 years@Mushy: The chief question you need to answer is that of ownership. Nothing else matters in the choice of a smart pointer, and that is answered very well in the questions I linked to. The question you linked to had my downvote (from earlier) because it shows nothing definitive at all and asks the wrong question about the "data".
-
Mushy about 11 yearsstackoverflow.com/questions/8706192/… is probably closest to my question in overall meaning and intent. I did not see stackoverflow.com/questions/8706192/… when researching or posting my question from the closest recommendations offered.
-
-
Puppy about 11 years
=default
and implicit move members can easily take care of the extra code. -
Cubic about 11 yearsIf you didn't need an explicit move constructor before adding a
unique_ptr
, you don't need an explicit move constructor afterwards. The only situation in which you'd have to write more code is when you'd have done something that disables the implicit move constructor. -
Kate Gregory about 11 years@DeadMG I'm still waiting for =default in my compiler, but yes
-
rubenvb about 11 years@KateGregory Use another compiler
;-)