What is the difference between an empty and a null std::shared_ptr in C++?

Question

The cplusplus.com shared_ptr page calls out a distinction between an empty std::shared_ptr and a null shared_ptr. The cppreference.com page doesn't explicitly call out the distinction, but uses both "empty" and comparison to nullptr in its description of std::shared_ptr behavior.

Is there a difference between an empty and a null shared_ptr? Is there any use case for such mixed-behavior pointers? Does a non-empty null shared_ptr even make sense? Would there ever be a case in normal usage (i.e. if you didn't explicitly construct one) where you could end up with an empty-but-non-null shared_ptr?

And do any of these answers change if you're using the Boost version instead of the C++11 version?

Answer 1

It's a weird corner of shared_ptr behavior. It has a constructor that allows you to make a shared_ptr that owns something and points to something else:

template< class Y > 
shared_ptr( const shared_ptr<Y>& r, T *ptr );

The shared_ptr constructed using this constructor shares ownership with r, but points to whatever ptr points to (i.e., calling get() or operator->() will return ptr). This is handy for cases where ptr points to a subobject (e.g., a data member) of the object owned by r.

The page you linked calls a shared_ptr that owns nothing empty, and a shared_ptr that points to nothing (i.e., whose get() == nullptr) null. (Empty is used in this sense by the standard; null isn't.) You can construct a null-but-not-empty shared_ptr, but it won't be very useful. An empty-but-not-null shared_ptr is essentially a non-owning pointer, which can be used to do some weird things like passing a pointer to something allocated on the stack to a function expecting a shared_ptr (but I'd suggest punching whoever put shared_ptr inside the API first).

boost::shared_ptr also has this constructor, which they call the aliasing constructor.