84

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 no more pointer. Is there an actual useful use of std::unique_ptr::get?

Daniel Heilper
  • 1,182
  • 2
  • 17
  • 34
lezebulon
  • 7,607
  • 11
  • 42
  • 73
  • 3
    what if you want to pass a pointer to the object to a library, such as any OS call? – Mooing Duck May 29 '12 at 15:23
  • 2
    Here's a [use case for get](http://codereview.stackexchange.com/questions/4679/shared-ptr-and-file-for-wrapping-cstdio-update-also-dlfcn-h). – Kerrek SB May 29 '12 at 15:36
  • 3
    You can do `std::addressof(*p)` anyway. There's no need to pretend that the underlying pointer isn't here. – Luc Danton May 29 '12 at 15:55

6 Answers6

110

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.

bames53
  • 86,085
  • 15
  • 179
  • 244
87

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 );
Nikolai Fetissov
  • 82,306
  • 11
  • 110
  • 171
  • You could also use `&buffer[0]`, and then it still works if some uncouth hacker changes it back to a raw pointer. – user2023370 Oct 20 '21 at 14:07
39

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.

Nevin
  • 4,595
  • 18
  • 24
24

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.

R. Martinho Fernandes
  • 228,013
  • 71
  • 433
  • 510
  • Is there theoretically any performance difference? I've always done &* – Carbon Sep 04 '18 at 23:00
  • 1
    @Carbon: `&*` is probably theoretically faster since it doesn't have the predictability guarantee of `.get()` but subsequently it is practically more dangerous since [it can lead to undefined behavior](https://stackoverflow.com/questions/33441609/whats-with-unique-ptrget-instead-of). – Fake Code Monkey Rashid Sep 23 '20 at 11:37
-2

There is the obvious situation when you need to call a C API, or a poorly designed C++ API.

K-ballo
  • 80,396
  • 20
  • 159
  • 169
  • 10
    Why would a C++ API be "poorly designed" if it forces you to use a *specific* smart pointer implementation? Even moreso if the API itself does not claim ownership of the pointer? – Nicol Bolas May 29 '12 at 15:41
  • 1
    For 'poorly designed' read also 'old, from the time before smart pointers were in the standard library/people used Boost'. – Matthew Walton May 29 '12 at 15:41
  • 1
    @NicolBolas: I typically pass const-references or references to functions, if that reference dies at the end of the call. This makes the calling-code slightly clumsier, like `foo(*something)`, but I think it is a better design than using pointers there because it better protects against function-contract-bugs while not putting constraints on a pointer-type. – Sebastian Mach May 29 '12 at 15:51
-3

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.

Mikael
  • 27
  • 1
  • 4
    "The main advantage is that the unique pointer keeps track of how many other references there are to that pointer" This is true for shared_ptr, not unique_ptr. – Nebula Jul 09 '20 at 08:42
  • 5
    `std::unique_ptr` does not keep track, how many references there are to a pointer. They are unique, so there is exactly one reference. If you need reference counting, `std::shared_ptr` is the way to go. – Kai Petzke Jul 21 '20 at 08:39