How to pass std::unique_ptr around?

Question

I am having my first attempt at using C++11 unique_ptr; I am replacing a polymorphic raw pointer inside a project of mine, which is owned by one class, but passed around quite frequently.

I used to have functions like:

bool func(BaseClass* ptr, int other_arg) {   bool val;   // plain ordinary function that does something...   return val; } 

But I soon realized that I wouldn't be able to switch to:

bool func(std::unique_ptr<BaseClass> ptr, int other_arg); 

Because the caller would have to handle the pointer ownership to the function, what I don't want to. So, what is the best solution to my problem?

I though of passing the pointer as reference, like this:

bool func(const std::unique_ptr<BaseClass>& ptr, int other_arg); 

But I feel very uncomfortable in doing so, firstly because it seems non instinctive to pass something already typed as _ptr as reference, what would be a reference of a reference. Secondly because the function signature gets even bigger. Thirdly, because in the generated code, it would be necessary two consecutive pointer indirections to reach my variable.

Answer 1

If you want the function to use the pointee, pass a reference to it. There's no reason to tie the function to work only with some kind of smart pointer:

bool func(BaseClass& base, int other_arg); 

And at the call site use operator*:

func(*some_unique_ptr, 42); 

Alternatively, if the base argument is allowed to be null, keep the signature as is, and use the get() member function:

bool func(BaseClass* base, int other_arg); func(some_unique_ptr.get(), 42); 

Answer 2

The advantage of using std::unique_ptr<T> (aside from not having to remember to call delete or delete[] explicitly) is that it guarantees that a pointer is either nullptr or it points to a valid instance of the (base) object. I will come back to this after I answer your question, but the first message is DO use smart pointers to manage the lifetime of dynamically allocated objects.

Now, your problem is actually how to use this with your old code.

My suggestion is that if you don't want to transfer or share ownership, you should always pass references to the object. Declare your function like this (with or without const qualifiers, as needed):

bool func(BaseClass& ref, int other_arg) { ... } 

Then the caller, which has a std::shared_ptr<BaseClass> ptr will either handle the nullptr case or it will ask bool func(...) to compute the result:

if (ptr) {   result = func(*ptr, some_int); } else {   /* the object was, for some reason, either not created or destroyed */ } 

This means that any caller has to promise that the reference is valid and that it will continue to be valid throughout the execution of the function body.

---

Here is the reason why I strongly believe you should not pass raw pointers or references to smart pointers.

A raw pointer is only a memory address. Can have one of (at least) 4 meanings:

1. The address of a block of memory where your desired object is located. (the good)
2. The address 0x0 which you can be certain is not dereferencable and might have the semantics of "nothing" or "no object". (the bad)
3. The address of a block of memory which is outside of the addressable space of your process (dereferencing it will hopefully cause your program to crash). (the ugly)
4. The address of a block of memory which can be dereferenced but which doesn't contain what you expect. Maybe the pointer was accidentally modified and now it points to another writable address (of a completely other variable within your process). Writing to this memory location will cause lots of fun to happen, at times, during the execution, because the OS will not complain as long as you are allowed to write there. (Zoinks!)

Correctly using smart pointers alleviates the rather scary cases 3 and 4, which are usually not detectable at compile time and which you generally only experience at runtime when your program crashes or does unexpected things.

Passing smart pointers as arguments has two disadvantages: you cannot change the const-ness of the pointed object without making a copy (which adds overhead for shared_ptr and is not possible for unique_ptr), and you are still left with the second (nullptr) meaning.

I marked the second case as (the bad) from a design perspective. This is a more subtle argument about responsibility.

Imagine what it means when a function receives a nullptr as its parameter. It first has to decide what to do with it: use a "magical" value in place of the missing object? change behavior completely and compute something else (which doesn't require the object)? panic and throw an exception? Moreover, what happens when the function takes 2, or 3 or even more arguments by raw pointer? It has to check each of them and adapt its behavior accordingly. This adds a whole new level on top of input validation for no real reason.

The caller should be the one with enough contextual information to make these decisions, or, in other words, the bad is less frightening the more you know. The function, on the other hand, should just take the caller's promise that the memory it is pointed to is safe to work with as intended. (References are still memory addresses, but conceptually represent a promise of validity.)