# shared_ptr class template

Introduction
Best Practices
Synopsis
Members
Free Functions
Example
Handle/Body Idiom
Thread Safety
Frequently Asked Questions
Smart Pointer Timings
Programming Techniques

## Introduction

The shared_ptr class template stores a pointer to a dynamically allocated object, typically with a C++ new-expression . The object pointed to is guaranteed to be deleted when the last shared_ptr pointing to it is destroyed or reset. See the example.

Every shared_ptr meets the CopyConstructible and Assignable requirements of the C++ Standard Library, and so can be used in standard library containers. Comparison operators are supplied so that shared_ptr works with the standard library's associative containers.

Normally, a shared_ptr cannot correctly hold a pointer to a dynamically allocated array. See shared_array for that usage.

Because the implementation uses reference counting, cycles of shared_ptr instances will not be reclaimed. For example, if main() holds a shared_ptr to A, which directly or indirectly holds a shared_ptr back to A, A's use count will be 2. Destruction of the original shared_ptr will leave A dangling with a use count of 1. Use weak_ptr to "break cycles."

The class template is parameterized on T, the type of the object pointed to. shared_ptr and most of its member functions place no requirements on T; it is allowed to be an incomplete type, or void. Member functions that do place additional requirements (constructors, reset) are explicitly documented below.

shared_ptr<T> can be implicitly converted to shared_ptr<U> whenever T* can be implicitly converted to U*. In particular, shared_ptr<T> is implicitly convertible to shared_ptr<T const>, to shared_ptr<U> where U is an accessible base of T, and to shared_ptr<void>.

## Best Practices

A simple guideline that nearly eliminates the possibility of memory leaks is: always use a named smart pointer variable to hold the result of new. Every occurence of the new keyword in the code should have the form:

    shared_ptr<T> p(new Y);

It is, of course, acceptable to use another smart pointer in place of shared_ptr above; having T and Y be the same type, or passing arguments to Y's constructor is also OK.

If you observe this guideline, it naturally follows that you will have no explicit deletes; try/catch constructs will be rare.

Avoid using unnamed shared_ptr temporaries to save typing; to see why this is dangerous, consider this example:

    void f(shared_ptr<int>, int);
    int g();

    void ok()
    {
        shared_ptr<int> p(new int(2));
        f(p, g());
    }

    void bad()
    {
        f(shared_ptr<int>(new int(2)), g());
    }

The function ok follows the guideline to the letter, whereas bad constructs the temporary shared_ptr in place, admitting the possibility of a memory leak. Since function arguments are evaluated in unspecified order, it is possible for new int(2) to be evaluated first, g() second, and we may never get to the shared_ptr constructor if g throws an exception. See Herb Sutter's treatment (also here) of the issue for more information.

## Synopsis

    namespace boost {

      class bad_weak_ptr: public std::exception;

      template<class T> class weak_ptr;

      template<class T> class shared_ptr {

        public:

          typedef T element_type;

          shared_ptr(); // never throws
          template<class Y> explicit shared_ptr(Y * p);
          template<class Y, class D> shared_ptr(Y * p, D d);
          ~shared_ptr(); // never throws

          shared_ptr(shared_ptr const & r); // never throws
          template<class Y> shared_ptr(shared_ptr<Y> const & r); // never throws
          template<class Y> explicit shared_ptr(weak_ptr<Y> const & r);
          template<class Y> explicit shared_ptr(std::auto_ptr<Y> & r);

          shared_ptr & operator=(shared_ptr const & r); // never throws
          template<class Y> shared_ptr & operator=(shared_ptr<Y> const & r); // never throws
          template<class Y> shared_ptr & operator=(std::auto_ptr<Y> & r);

          void reset(); // never throws
          template<class Y> void reset(Y * p);
          template<class Y, class D> void reset(Y * p, D d);

          T & operator*() const; // never throws
          T * operator->() const; // never throws
          T * get() const; // never throws

          bool unique() const; // never throws
          long use_count() const; // never throws

          operator unspecified-bool-type() const; // never throws

          void swap(shared_ptr & b); // never throws
      };

      template<class T, class U>
        bool operator==(shared_ptr<T> const & a, shared_ptr<U> const & b); // never throws

      template<class T, class U>
        bool operator!=(shared_ptr<T> const & a, shared_ptr<U> const & b); // never throws

      template<class T, class U>
        bool operator<(shared_ptr<T> const & a, shared_ptr<U> const & b); // never throws

      template<class T> void swap(shared_ptr<T> & a, shared_ptr<T> & b); // never throws

      template<class T> T * get_pointer(shared_ptr<T> const & p); // never throws

      template<class T, class U>
        shared_ptr<T> static_pointer_cast(shared_ptr<U> const & r); // never throws

      template<class T, class U>
        shared_ptr<T> dynamic_pointer_cast(shared_ptr<U> const & r); // never throws

      template<class E, class T, class Y>
        std::basic_ostream<E, T> & operator<< (std::basic_ostream<E, T> & os, shared_ptr<Y> const & p);

      template<class D, class T>
        D * get_deleter(shared_ptr<T> const & p);
    }

[It might be convenient to relax the requirements on shared_ptr's signature, allowing an additional, defaulted, template parameter; the parameter can encode the threading model, for example. This would help in detecting possible ODR violations.

On the other hand, using shared_ptr as an argument to a template template parameter requires an exact signature match. Metaprogramming experts tend to deemphasize template template parameters as they are too inflexible, but the alternative is typically an std::allocator::rebind-type "hack".]

## Members

### element_type

    typedef T element_type;

> Provides the type of the template parameter T.

### constructors

    shared_ptr(); // never throws

> Effects: Constructs an empty shared_ptr. Empty shared_ptr objects have an unspecified use_count.

> Postconditions: `get() == 0`.

> Throws: nothing.

[The nothrow guarantee is important, since reset() is specified in terms of the default constructor; this implies that the constructor must not allocate memory.

There are two possible implementations, one stores 0 as a pointer to the reference count, the other uses a single statically allocated count for all default-constructed shared_ptrs. The second option is difficult to achieve in the current header-only reference implementation due to thread safety issues and initialization order, but it should not be precluded by the specification. That's why the use_count() has been left unspecified.

A future release may enable shared_ptr construction from a literal zero, for consistency with built-in pointers. It is not clear yet whether this constructor should be left implicit, enabling 0 to be used as a shorthand for shared_ptr<T>().]

    template<class Y> explicit shared_ptr(Y * p);

> Requirements: p must be convertible to T *. Y must be a complete type. The expression `delete p` must be well-formed, must not invoke undefined behavior, and must not throw exceptions.

> Effects: Constructs a shared_ptr that owns the pointer p.

> Postconditions: `use_count() == 1 && get() == p`.

> Throws: std::bad_alloc or an implementation-defined exception when a resource other than memory could not be obtained.

> Exception safety: If an exception is thrown, `delete p` is called.

> Notes: p must be a pointer to an object that was allocated via a C++ new expression or be 0. The postcondition that use count is 1 holds even if p is 0; invoking delete on a pointer that has a value of 0 is harmless.

[This constructor has been changed to a template in order to remember the actual pointer type passed. The destructor will call delete with the same pointer, complete with its original type, even when T does not have a virtual destructor, or is void.

The optional intrusive counting support has been dropped as it exposes too much implementation details and doesn't interact well with weak_ptr. The current implementation uses a different mechanism, enable_shared_from_this, to solve the "shared_ptr from this" problem.]

    template<class Y, class D> shared_ptr(Y * p, D d);

> Requirements: p must be convertible to T *. D must be CopyConstructible. The copy constructor and destructor of D must not throw. The expression `d(p)` must be well-formed, must not invoke undefined behavior, and must not throw exceptions.

> Effects: Constructs a shared_ptr that owns the pointer p and the deleter d.

> Postconditions: `use_count() == 1 && get() == p`.

> Throws: std::bad_alloc or an implementation-defined exception when a resource other than memory could not be obtained.

> Exception safety: If an exception is thrown, `d(p)` is called.

> Notes: When the the time comes to delete the object pointed to by p, the stored copy of d is invoked with the stored copy of p as an argument.

[Custom deallocators allow a factory function returning a shared_ptr to insulate the user from its memory allocation strategy. Since the deallocator is not part of the type, changing the allocation strategy does not break source or binary compatibility, and does not require a client recompilation. For example, a "no-op" deallocator is useful when returning a shared_ptr to a statically allocated object, and other variations allow a shared_ptr to be used as a wrapper for another smart pointer, easing interoperability.

The support for custom deallocators does not impose significant overhead. Other shared_ptr features still require a deallocator to be kept.

The requirement that the copy constructor of D does not throw comes from the pass by value. If the copy constructor throws, the pointer is leaked. Removing the requirement requires a pass by (const) reference.

Pass by reference is problematic since (1) pass by value conveniently changes functions (function references) to function pointers (this has to be performed manually otherwise and some compilers may not be able to do it) and (2) const references don't currently (per the standard) bind to functions. This can be solved (I think) but it requires an overload set that breaks on many compilers due to 14.5.5.2 problems (and of course it will break on compilers that don't do partial ordering at all.)

The main problem with pass by reference, though, lies in its interaction with rvalues. A const reference may still cause a copy, and will require a const operator(). A non-const reference won't bind to an rvalue at all. A good solution to this problem is the rvalue reference proposed in N1377/N1385.]

    shared_ptr(shared_ptr const & r); // never throws
    template<class Y> shared_ptr(shared_ptr<Y> const & r); // never throws

> Effects: If r is empty, constructs an empty shared_ptr; otherwise, constructs a shared_ptr that shares ownership with r.

> Postconditions: `get() == r.get() && use_count() == r.use_count()`.

> Throws: nothing.

    template<class Y> explicit shared_ptr(weak_ptr<Y> const & r);

> Effects: If r is empty, constructs an empty shared_ptr; otherwise, constructs a shared_ptr that shares ownership with r and stores a copy of the pointer stored in r.

> Postconditions: `use_count() == r.use_count()`.

> Throws: bad_weak_ptr when `r.use_count() == 0`.

> Exception safety: If an exception is thrown, the constructor has no effect.

    template<class Y> shared_ptr(std::auto_ptr<Y> & r);

> Effects: Constructs a shared_ptr, as if by storing a copy of r.release().

> Postconditions: `use_count() == 1`.

> Throws: std::bad_alloc or an implementation-defined exception when a resource other than memory could not be obtained.

> Exception safety: If an exception is thrown, the constructor has no effect.

[This constructor takes a the source auto_ptr by reference and not by value, and cannot accept auto_ptr temporaries. This is by design, as the constructor offers the strong guarantee; an rvalue reference would solve this problem, too.]

### destructor

    ~shared_ptr(); // never throws

> Effects:

> - If *this is empty, or shares ownership with another shared_ptr instance (`use_count() > 1`), there are no side effects.
> - Otherwise, if *this owns a pointer p and a deleter d, `d(p)` is called.
> - Otherwise, *this owns a pointer p, and `delete p` is called.

> Throws: nothing.

### assignment

    shared_ptr & operator=(shared_ptr const & r); // never throws
    template<class Y> shared_ptr & operator=(shared_ptr<Y> const & r); // never throws
    template<class Y> shared_ptr & operator=(std::auto_ptr<Y> & r);

> Effects: Equivalent to `shared_ptr(r).swap(*this)`.

> Returns: `*this`.

> Notes: The use count updates caused by the temporary object construction and destruction are not considered observable side effects, and the implementation is free to meet the effects (and the implied guarantees) via different means, without creating a temporary. In particular, in the example:

>     shared_ptr<int> p(new int);
>     shared_ptr<void> q(p);
>     p = p;
>     q = p;

> both assignments may be no-ops.

[Some experts consider the note to be redundant, as it appears to essentially mirror the "as if" rule. However, experience suggests that when C++ code is used to describe effects, it is often misinterpreted as required implementation. In addition, it is not entirely clear whether the "as if" rule actually applies here, so it's better to be explicit about the possible optimizations.]

### reset

    void reset(); // never throws

> Effects: Equivalent to `shared_ptr().swap(*this)`.

    template<class Y> void reset(Y * p);

> Effects: Equivalent to `shared_ptr(p).swap(*this)`.

    template<class Y, class D> void reset(Y * p, D d);

> Effects: Equivalent to `shared_ptr(p, d).swap(*this)`.

### indirection

    T & operator*() const; // never throws

> Requirements: The stored pointer must not be 0.

> Returns: a reference to the object pointed to by the stored pointer.

> Throws: nothing.

    T * operator->() const; // never throws

> Requirements: The stored pointer must not be 0.

> Returns: the stored pointer.

> Throws: nothing.

### get

    T * get() const; // never throws

> Returns: the stored pointer.

> Throws: nothing.

### unique

    bool unique() const; // never throws

> Returns: `use_count() == 1`.

> Throws: nothing.

> Notes: `unique()` may be faster than `use_count()`. If you are using `unique()` to implement copy on write, do not rely on a specific value when the stored pointer is zero.

### use_count

    long use_count() const; // never throws

> Returns: the number of shared_ptr objects, *this included, that share ownership with *this, or an unspecified nonnegative value when *this is empty.

> Throws: nothing.

> Notes: `use_count()` is not necessarily efficient. Use only for debugging and testing purposes, not for production code.

### conversions

    operator unspecified-bool-type () const; // never throws

> Returns: an unspecified value that, when used in boolean contexts, is equivalent to `get() != 0`.

> Throws: nothing.

> Notes: This conversion operator allows shared_ptr objects to be used in boolean contexts, like `if (p && p->valid()) {}`. The actual target type is typically a pointer to a member function, avoiding many of the implicit conversion pitfalls.

[The conversion to bool is not merely syntactic sugar. It allows shared_ptrs to be declared in conditions when using dynamic_pointer_cast or weak_ptr::lock.]

### swap

    void swap(shared_ptr & b); // never throws

> Effects: Exchanges the contents of the two smart pointers.

> Throws: nothing.

## Free Functions

### comparison

    template<class T, class U>
      bool operator==(shared_ptr<T> const & a, shared_ptr<U> const & b); // never throws

> Returns: `a.get() == b.get()`.

> Throws: nothing.

    template<class T, class U>
      bool operator!=(shared_ptr<T> const & a, shared_ptr<U> const & b); // never throws

> Returns: `a.get() != b.get()`.

> Throws: nothing.

    template<class T, class U>
      bool operator<(shared_ptr<T> const & a, shared_ptr<U> const & b); // never throws

> Returns: an unspecified value such that

> - operator< is a strict weak ordering as described in section 25.3 `[lib.alg.sorting]` of the C++ standard;
> - under the equivalence relation defined by operator<, `!(a < b) && !(b < a)`, two shared_ptr instances are equivalent if and only if they share ownership.

> Throws: nothing.

> Notes: Allows shared_ptr objects to be used as keys in associative containers.

[Operator< has been preferred over a std::less specialization for consistency and legality reasons, as std::less is required to return the results of operator<, and many standard algorithms use operator< instead of std::less for comparisons when a predicate is not supplied. Composite objects, like std::pair, also implement their operator< in terms of their contained subobjects' operator<.

The rest of the comparison operators are omitted by design.]

### swap

    template<class T>
      void swap(shared_ptr<T> & a, shared_ptr<T> & b); // never throws

> Effects: Equivalent to `a.swap(b)`.

> Throws: nothing.

> Notes: Matches the interface of std::swap. Provided as an aid to generic programming.

[swap is defined in the same namespace as shared_ptr as this is currently the only legal way to supply a swap function that has a chance to be used by the standard library.]

### get_pointer

    template<class T>
      T * get_pointer(shared_ptr<T> const & p); // never throws

> Returns: `p.get()`.

> Throws: nothing.

> Notes: Provided as an aid to generic programming. Used by mem_fn.

### static_pointer_cast

    template<class T, class U>
      shared_ptr<T> static_pointer_cast(shared_ptr<U> const & r); // never throws

> Requires: The expression `static_cast<T*>(r.get())` must be well-formed.

> Returns: If r is empty, an empty shared_ptr<T>; otherwise, a shared_ptr<T> object that stores a copy of `static_cast<T*>(r.get())` and shares ownership with r.

> Throws: nothing.

> Notes: the seemingly equivalent expression

> `shared_ptr<T>(static_cast<T*>(r.get()))`

> will eventually result in undefined behavior, attempting to delete the same object twice.

### dynamic_pointer_cast

    template<class T, class U>
      shared_ptr<T> dynamic_pointer_cast(shared_ptr<U> const & r);

> Requires: The expression `dynamic_cast<T*>(r.get())` must be well-formed and its behavior defined.

> Returns:

> - When `dynamic_cast<T*>(r.get())` returns a nonzero value, a shared_ptr<T> object that stores a copy of it and shares ownership with r;
> - Otherwise, an empty shared_ptr<T> object.

> Throws: nothing.

> Notes: the seemingly equivalent expression

> `shared_ptr<T>(dynamic_cast<T*>(r.get()))`

> will eventually result in undefined behavior, attempting to delete the same object twice.

### operator<<

    template<class E, class T, class Y>
        std::basic_ostream<E, T> & operator<< (std::basic_ostream<E, T> & os, shared_ptr<Y> const & p);

> Effects: `os << p.get();`.

> Returns: os.

### get_deleter

    template<class D, class T>
        D * get_deleter(shared_ptr<T> const & p);

> Returns: If *this owns a deleter d of type (cv-unqualified) D, returns `&d`; otherwise returns 0.

## Example

See shared_ptr_example.cpp for a complete example program. The program builds a std::vector and std::set of shared_ptr objects.

Note that after the containers have been populated, some of the shared_ptr objects will have a use count of 1 rather than a use count of 2, since the set is a std::set rather than a std::multiset, and thus does not contain duplicate entries. Furthermore, the use count may be even higher at various times while push_back and insert container operations are performed. More complicated yet, the container operations may throw exceptions under a variety of circumstances. Getting the memory management and exception handling in this example right without a smart pointer would be a nightmare.

## Handle/Body Idiom

One common usage of shared_ptr is to implement a handle/body (also called pimpl) idiom which avoids exposing the body (implementation) in the header file.

The shared_ptr_example2_test.cpp sample program includes a header file, shared_ptr_example2.hpp, which uses a shared_ptr<> to an incomplete type to hide the implementation. The instantiation of member functions which require a complete type occurs in the shared_ptr_example2.cpp implementation file. Note that there is no need for an explicit destructor. Unlike ~scoped_ptr, ~shared_ptr does not require that T be a complete type.

## Thread Safety

shared_ptr objects offer the same level of thread safety as built-in types. A shared_ptr instance can be "read" (accessed using only const operations) simultaneously by multiple threads. Different shared_ptr instances can be "written to" (accessed using mutable operations such as operator= or reset) simultaneosly by multiple threads (even when these instances are copies, and share the same reference count underneath.)

Any other simultaneous accesses result in undefined behavior.

Examples:

    shared_ptr<int> p(new int(42));

    //--- Example 1 ---

    // thread A
    shared_ptr<int> p2(p); // reads p

    // thread B
    shared_ptr<int> p3(p); // OK, multiple reads are safe

    //--- Example 2 ---

    // thread A
    p.reset(new int(1912)); // writes p

    // thread B
    p2.reset(); // OK, writes p2

    //--- Example 3 ---

    // thread A
    p = p3; // reads p3, writes p

    // thread B
    p3.reset(); // writes p3; undefined, simultaneous read/write

    //--- Example 4 ---

    // thread A
    p3 = p2; // reads p2, writes p3

    // thread B
    // p2 goes out of scope: undefined, the destructor is considered a "write access"

    //--- Example 5 ---

    // thread A
    p3.reset(new int(1));

    // thread B
    p3.reset(new int(2)); // undefined, multiple writes

shared_ptr uses Boost.Config to detect whether the implementation supports threads. If your program is single-threaded, but your platform is autodetected by Boost.Config as supporting multiple threads, #define BOOST_DISABLE_THREADS to eliminate the thread safety overhead.

## Frequently Asked Questions

Q. There are several variations of shared pointers, with different tradeoffs; why does the smart pointer library supply only a single implementation? It would be useful to be able to experiment with each type so as to find the most suitable for the job at hand?

A. An important goal of shared_ptr is to provide a standard shared-ownership pointer. Having a single pointer type is important for stable library interfaces, since different shared pointers typically cannot interoperate, i.e. a reference counted pointer (used by library A) cannot share ownership with a linked pointer (used by library B.)

Q. Why doesn't shared_ptr have template parameters supplying traits or policies to allow extensive user customization?

A. Parameterization discourages users. The shared_ptr template is carefully crafted to meet common needs without extensive parameterization. Some day a highly configurable smart pointer may be invented that is also very easy to use and very hard to misuse. Until then, shared_ptr is the smart pointer of choice for a wide range of applications. (Those interested in policy based smart pointers should read Modern C++ Design by Andrei Alexandrescu.)

Q. I am not convinced. Default parameters can be used where appropriate to hide the complexity. Again, why not policies?

A. Template parameters affect the type. See the answer to the first question above.

Q. Why doesn't shared_ptr use a linked list implementation?

A. A linked list implementation does not offer enough advantages to offset the added cost of an extra pointer. See timings page. In addition, it is expensive to make a linked list implementation thread safe.

Q. Why doesn't shared_ptr (or any of the other Boost smart pointers) supply an automatic conversion to T*?

A. Automatic conversion is believed to be too error prone.

Q. Why does shared_ptr supply use_count()?

A. As an aid to writing test cases and debugging displays. One of the progenitors had use_count(), and it was useful in tracking down bugs in a complex project that turned out to have cyclic-dependencies.

Q. Why doesn't shared_ptr specify complexity requirements?

A. Because complexity requirements limit implementors and complicate the specification without apparent benefit to shared_ptr users. For example, error-checking implementations might become non-conforming if they had to meet stringent complexity requirements.

Q. Why doesn't shared_ptr provide a release() function?

A. shared_ptr cannot give away ownership unless it's unique() because the other copy will still destroy the object.

Consider:

>     shared_ptr<int> a(new int);
>     shared_ptr<int> b(a); // a.use_count() == b.use_count() == 2

>     int * p = a.release();

>     // Who owns p now? b will still call delete on it in its destructor.

Furthermore, the pointer returned by `release()` would be difficult to deallocate reliably, as the source shared_ptr could have been created with a custom deleter.

Q. Why is `operator->()` const, but its return value is a non-const pointer to the element type?

A. Shallow copy pointers, including raw pointers, typically don't propagate constness. It makes little sense for them to do so, as you can always obtain a non-const pointer from a const one and then proceed to modify the object through it.shared_ptr is "as close to raw pointers as possible but no closer".

$Date: 2003/02/13 19:07:19 $

Copyright 1999 Greg Colvin and Beman Dawes. Copyright 2002 Darin Adler. Copyright 2002, 2003 Peter Dimov. Permission to copy, use, modify, sell and distribute this document is granted provided this copyright notice appears in all copies. This document is provided "as is" without express or implied warranty, and with no claim as to its suitability for any purpose.