Categories
c++ c++-faq c++11 pointers smart-pointers

What is a smart pointer and when should I use one?

2073

What is a smart pointer and when should I use one?

6

2014

UPDATE

This answer is rather old, and so describes what was ‘good’ at the time, which was smart pointers provided by the Boost library. Since C++11, the standard library has provided sufficient smart pointers types, and so you should favour the use of std::unique_ptr, std::shared_ptr and std::weak_ptr.

There was also std::auto_ptr. It was very much like a scoped pointer, except that it also had the “special” dangerous ability to be copied — which also unexpectedly transfers ownership.
It was deprecated in C++11 and removed in C++17, so you shouldn’t use it.

std::auto_ptr<MyObject> p1 (new MyObject());
std::auto_ptr<MyObject> p2 = p1; // Copy and transfer ownership. 
                                 // p1 gets set to empty!
p2->DoSomething(); // Works.
p1->DoSomething(); // Oh oh. Hopefully raises some NULL pointer exception.

OLD ANSWER

A smart pointer is a class that wraps a ‘raw’ (or ‘bare’) C++ pointer, to manage the lifetime of the object being pointed to. There is no single smart pointer type, but all of them try to abstract a raw pointer in a practical way.

Smart pointers should be preferred over raw pointers. If you feel you need to use pointers (first consider if you really do), you would normally want to use a smart pointer as this can alleviate many of the problems with raw pointers, mainly forgetting to delete the object and leaking memory.

With raw pointers, the programmer has to explicitly destroy the object when it is no longer useful.

// Need to create the object to achieve some goal
MyObject* ptr = new MyObject(); 
ptr->DoSomething(); // Use the object in some way
delete ptr; // Destroy the object. Done with it.
// Wait, what if DoSomething() raises an exception...?

A smart pointer by comparison defines a policy as to when the object is destroyed. You still have to create the object, but you no longer have to worry about destroying it.

SomeSmartPtr<MyObject> ptr(new MyObject());
ptr->DoSomething(); // Use the object in some way.

// Destruction of the object happens, depending 
// on the policy the smart pointer class uses.

// Destruction would happen even if DoSomething() 
// raises an exception

The simplest policy in use involves the scope of the smart pointer wrapper object, such as implemented by boost::scoped_ptr or std::unique_ptr.

void f()
{
    {
       std::unique_ptr<MyObject> ptr(new MyObject());
       ptr->DoSomethingUseful();
    } // ptr goes out of scope -- 
      // the MyObject is automatically destroyed.

    // ptr->Oops(); // Compile error: "ptr" not defined
                    // since it is no longer in scope.
}

Note that std::unique_ptr instances cannot be copied. This prevents the pointer from being deleted multiple times (incorrectly). You can, however, pass references to it around to other functions you call.

std::unique_ptrs are useful when you want to tie the lifetime of the object to a particular block of code, or if you embedded it as member data inside another object, the lifetime of that other object. The object exists until the containing block of code is exited, or until the containing object is itself destroyed.

A more complex smart pointer policy involves reference counting the pointer. This does allow the pointer to be copied. When the last “reference” to the object is destroyed, the object is deleted. This policy is implemented by boost::shared_ptr and std::shared_ptr.

void f()
{
    typedef std::shared_ptr<MyObject> MyObjectPtr; // nice short alias
    MyObjectPtr p1; // Empty

    {
        MyObjectPtr p2(new MyObject());
        // There is now one "reference" to the created object
        p1 = p2; // Copy the pointer.
        // There are now two references to the object.
    } // p2 is destroyed, leaving one reference to the object.
} // p1 is destroyed, leaving a reference count of zero. 
  // The object is deleted.

Reference counted pointers are very useful when the lifetime of your object is much more complicated, and is not tied directly to a particular section of code or to another object.

There is one drawback to reference counted pointers — the possibility of creating a dangling reference:

// Create the smart pointer on the heap
MyObjectPtr* pp = new MyObjectPtr(new MyObject())
// Hmm, we forgot to destroy the smart pointer,
// because of that, the object is never destroyed!

Another possibility is creating circular references:

struct Owner {
   std::shared_ptr<Owner> other;
};

std::shared_ptr<Owner> p1 (new Owner());
std::shared_ptr<Owner> p2 (new Owner());
p1->other = p2; // p1 references p2
p2->other = p1; // p2 references p1

// Oops, the reference count of of p1 and p2 never goes to zero!
// The objects are never destroyed!

To work around this problem, both Boost and C++11 have defined a weak_ptr to define a weak (uncounted) reference to a shared_ptr.

18

  • 7

    Do you mean std::auto_ptr<MyObject> p1 (new MyObject()); instead of std::auto_ptr<MyObject> p1 (new Owner());?

    Jul 16, 2011 at 23:06

  • 39

    Awesome answer. It would be nice if it were updated for c++11. I found this answer looking for info about the new 11 standard and it would be nice if future visitors could find the updated info. I know auto_ptr has been deprecated. I believe shated_ptr and weak_ptr exist as described, and I think the scoped_ptr is now unique_ptr in the standard. If this is true, can this answer be updated please?

    – SaulBack

    Sep 11, 2012 at 20:50

  • 24

    To say that the possibility of creating a dangling reference is a drawback to reference counted pointers is absolutely insane. Possible dangling references are a drawback of any C++ pointer. In fact, it is exactly that drawback which smart pointers are intended to alleviate.

    Aug 13, 2014 at 21:59


  • 27

    If you declare a pointer to a smart pointer (as was done in the example) you knowingly give up all benefits of the smart pointer. This is not a drawback or a design flaw, it is the most idiotic usage imaginable.

    Aug 13, 2014 at 22:02


  • 3

    A const std::auto_ptr is safe to use, if you’re stuck with C++03. I used it for pimpl pattern quite a lot until I got access to C++11.

    Sep 17, 2015 at 11:55

393

Here’s a simple answer for these days of modern C++ (C++11 and later):

  • “What is a smart pointer?”
    It’s a type whose values can be used like pointers, but which provides the additional feature of automatic memory management: When a smart pointer is no longer in use, the memory it points to is deallocated (see also the more detailed definition on Wikipedia).
  • “When should I use one?”
    In code which involves tracking the ownership of a piece of memory, allocating or de-allocating; the smart pointer often saves you the need to do these things explicitly.
  • “But which smart pointer should I use in which of those cases?”
    • Use std::unique_ptr when you want your object to live just as long as a single owning reference to it lives. For example, use it for a pointer to memory which gets allocated on entering some scope and de-allocated on exiting the scope.
    • Use std::shared_ptr when you do want to refer to your object from multiple places – and do not want your object to be de-allocated until all these references are themselves gone.
    • Use std::weak_ptr when you do want to refer to your object from multiple places – for those references for which it’s ok to ignore and deallocate (so they’ll just note the object is gone when you try to dereference).
    • Don’t use the boost:: smart pointers or std::auto_ptr except in special cases which you can read up on if you must.
    • There is a proposal to add hazard pointers to C++26, but for now you don’t have them.
  • “Hey, I didn’t ask which one to use!”
    Ah, but you really wanted to, admit it.
  • “So when should I use regular pointers then?”
    Mostly in code that is oblivious to memory ownership. This would typically be in functions which get a pointer from someplace else and do not allocate nor de-allocate, and do not store a copy of the pointer which outlasts their execution.

4

  • 14

    It is worth noting that while smart (owning) pointers help with proper memory management, raw (non-owning) pointers are still useful for other organizational purposes in data structures. Herb Sutter gave a great presentation upon this matter at CppCon 2016, that you can see on YouTube: Leak-Freedom in C++… By Default.

    Nov 13, 2016 at 23:22

  • 1

    @wiktor.wandachowicz T* is to std::unique_ptr<T> what std::weak_ptr<T> is to std::shared_ptr<T>

    – Caleth

    Sep 17, 2019 at 12:50

  • 3

    @Caleth: No, I wouldn’t say that.

    – einpoklum

    Sep 17, 2019 at 14:27

  • @Caleth That is not accurate. T* is to std::unique_ptr<T> what T* is to std::shared_ptr<T>. In both cases, if you want a non-owning pointer to the managed object you should use a raw pointer. weak_ptr is not well suited for that purpose.

    Mar 22 at 13:58


116

A smart pointer is a pointer-like type with some additional functionality, e.g. automatic memory deallocation, reference counting etc.

A small intro is available on the page Smart Pointers – What, Why, Which?.

One of the simple smart-pointer types is std::auto_ptr (chapter 20.4.5 of C++ standard), which allows one to deallocate memory automatically when it out of scope and which is more robust than simple pointer usage when exceptions are thrown, although less flexible.

Another convenient type is boost::shared_ptr which implements reference counting and automatically deallocates memory when no references to the object remains. This helps avoiding memory leaks and is easy to use to implement RAII.

The subject is covered in depth in book “C++ Templates: The Complete Guide” by David Vandevoorde, Nicolai M. Josuttis, chapter Chapter 20. Smart Pointers.
Some topics covered:

1

  • 5

    Warning std::auto_ptr is deprecated and highly discourage as you can accidentally transfer ownership. — C++11 removes the need of Boost, use: std::unique_ptr, std::shared_ptr and std::weak_ptr

    – ninMonkey

    Jun 12, 2019 at 13:38