Doesn\'t std::unique_ptr::get
defeat the purpose of having a unique_ptr in the first place?
I would have expected this function to change its state so it holds
Herb Sutter has a good explanation (around 3:40) https://www.youtube.com/watch?v=JfmTagWcqoE
The main advantage is that the unique pointer keeps track of how many other references there are to that pointer. You only work with the unique pointer when you are working with ownership. When you want to do something with the data with that pointer, you pass the raw pointer.
The rule I tend to follow is this: if the callee isn't mucking with lifetime/ownership, do not pass it a smart pointer; rather, pass in a raw C++ reference (preferred) or raw pointer. I find it far cleaner and more flexible to separate the concern of ownership from usage.
std::unique_ptr
provides unique ownership semantics safely. However that doesn't rule out the need for non-owning pointers. std::shared_ptr
has a non-owning counterpart, std::weak_ptr
. Raw pointers operate as std::unique_ptr
's non-owning counterpart.
There is the obvious situation when you need to call a C API, or a poorly designed C++ API.
When your hands are tied and you do need to pass a pointer to something, p.get()
reads better than &*p
.
There is a function that changes the state so the unique_ptr
doesn't hold a pointer anymore, and that one is named release
. This is mostly useful to transfer ownership to other smart pointers that don't provide direct construction from a unique_ptr
. Any other use risks leaking the resource.
You use it every time you need to pass raw pointer to, say, a C function:
std::unique_ptr<char[]> buffer( new char[1024] );
// ... fill the buffer
int rc = ::write( fd, buffer.get(), len );