What is the best smart pointer return type for a factory function?

Question

With respect to smart pointers and new C++11/14 features, I am wondering what the best-practice return values and function parameter types would be for classes that have the

Answer 1

Most of the other answers cover this, but @T.C. linked to a few really good guidelines which I'd like to summarise here:

Factory function

A factory that produces a reference type should return a unique_ptr by default, or a shared_ptr if ownership is to be shared with the factory. -- GotW #90

As others have pointed out, you as the recipient of the unique_ptr can convert it to a shared_ptr if you wish.

Function parameters

Don’t pass a smart pointer as a function parameter unless you want to use or manipulate the smart pointer itself, such as to share or transfer ownership. Prefer passing objects by value, *, or &, not by smart pointer. -- GotW #91

This is because when you pass by smart pointer, you increment the reference counter at the start of the function, and decrement it at the end. These are atomic operations, which require synchronisation across multiple threads/processors, so in heavily multithreaded code the speed penalty can be quite high.

When you're in the function the object is not going to disappear because the caller still holds a reference to it (and can't do anything with the object until your function returns) so incrementing the reference count is pointless if you're not going to keep a copy of the object after the function returns.

For functions that don't take ownership of the object:

Use a * if you need to express null (no object), otherwise prefer to use a &; and if the object is input-only, write const widget* or const widget&. -- GotW #91

This doesn't force your caller to use a particular smart pointer type - any smart pointer can be converted into a normal pointer or a reference. So if your function doesn't need to keep a copy of the object or take ownership of it, use a raw pointer. As above, the object won't disappear in the middle of your function because the caller is still holding on to it (except in special circumstances, which you would already be aware of if this is an issue for you.)

For functions that do take ownership of the object:

Express a “sink” function using a by-value unique_ptr parameter.

void f( unique_ptr );

-- GotW #91

This makes it clear the function takes ownership of the object, and it's possible to pass raw pointers to it that you might have from legacy code.

For functions that take shared ownership of the object:

Express that a function will store and share ownership of a heap object using a by-value shared_ptr parameter. -- GotW #91

I think these guidelines are very useful. Read the pages the quotes came from for more background and in-depth explanation, it's worth it.