Smart Pointers (Boost) Explained

smart pointers (boost) explained

Basic properties of smart pointers

It's easy when you have properties that you can assign each smart pointer. There are three important properties.

• no ownership at all
• transfer of ownership
• share of ownership

The first means that a smart pointer cannot delete the object, because it doesn't own it. The second means that only one smart pointer can ever point to the same object at the same time. If the smart pointer is to be returned from functions, the ownership is transferred to the returned smart pointer, for example.

The third means that multiple smart pointers can point to the same object at the same time. This applies to a raw pointer too, however raw pointers lack an important feature: They do not define whether they are owning or not. A share of ownership smart pointer will delete the object if every owner gives up the object. This behavior happens to be needed often, so shared owning smart pointers are widely spread.

Some owning smart pointers support neither the second nor the third. They can therefore not be returned from functions or passed somewhere else. Which is most suitable for RAII purposes where the smart pointer is kept local and is just created so it frees an object after it goes out of scope.

Share of ownership can be implemented by having a copy constructor. This naturally copies a smart pointer and both the copy and the original will reference the same object. Transfer of ownership cannot really be implemented in C++ currently, because there are no means to transfer something from one object to another supported by the language: If you try to return an object from a function, what is happening is that the object is copied. So a smart pointer that implements transfer of ownership has to use the copy constructor to implement that transfer of ownership. However, this in turn breaks its usage in containers, because requirements state a certain behavior of the copy constructor of elements of containers which is incompatible with this so-called "moving constructor" behavior of these smart pointers.

C++1x provides native support for transfer-of-ownership by introducing so-called "move constructors" and "move assignment operators". It also comes with such a transfer-of-ownership smart pointer called unique_ptr.

Categorizing smart pointers

scoped_ptr is a smart pointer that is neither transferable nor sharable. It's just usable if you locally need to allocate memory, but be sure it's freed again when it goes out of scope. But it can still be swapped with another scoped_ptr, if you wish to do so.

shared_ptr is a smart pointer that shares ownership (third kind above). It is reference counted so it can see when the last copy of it goes out of scope and then it frees the object managed.

weak_ptr is a non-owning smart pointer. It is used to reference a managed object (managed by a shared_ptr) without adding a reference count. Normally, you would need to get the raw pointer out of the shared_ptr and copy that around. But that would not be safe, as you would not have a way to check when the object was actually deleted. So, weak_ptr provides means by referencing an object managed by shared_ptr. If you need to access the object, you can lock the management of it (to avoid that in another thread a shared_ptr frees it while you use the object) and then use it. If the weak_ptr points to an object already deleted, it will notice you by throwing an exception. Using weak_ptr is most beneficial when you have a cyclic reference: Reference counting cannot easily cope with such a situation.

intrusive_ptr is like a shared_ptr but it does not keep the reference count in a shared_ptr but leaves incrementing/decrementing the count to some helper functions that need to be defined by the object that is managed. This has the advantage that an already referenced object (which has a reference count incremented by an external reference counting mechanism) can be stuffed into an intrusive_ptr - because the reference count is not anymore internal to the smart pointer, but the smart pointer uses an existing reference counting mechanism.

unique_ptr is a transfer of ownership pointer. You cannot copy it, but you can move it by using C++1x's move constructors:

unique_ptr<type> p(new type);
unique_ptr<type> q(p); // not legal!
unique_ptr<type> r(move(p)); // legal. p is now empty, but r owns the object
unique_ptr<type> s(function_returning_a_unique_ptr()); // legal!

This is the semantic that std::auto_ptr obeys, but because of missing native support for moving, it fails to provide them without pitfalls. unique_ptr will automatically steal resources from a temporary other unique_ptr which is one of the key features of move semantics. auto_ptr will be deprecated in the next C++ Standard release in favor of unique_ptr. C++1x will also allow stuffing objects that are only movable but not copyable into containers. So you can stuff unique_ptr's into a vector for example. I'll stop here and reference you to a fine article about this if you want to read more about this.

Boost smart pointers

When you already have a reference counter stored inside the object you're pointing to.

What is the difference between Boost smart pointers and std smart pointers?

Basically Boost did shared_ptr first. You may note that many of the new container classes in C++11 were in Boost long ago. I would expect this pattern to continue with the next revisions of the C++ standard, too. Boost supports older C++ compilers that don't talk C++11, which is a big benefit.

Incidentally, std::auto_ptr is deprecated in C++11, which brings in std::shared_ptr and std::unique_ptr instead, which are both significantly more useful.

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

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.

Can someone explain smart pointers in plain English?

Primarily, smart pointers help you to:

• Avoid leaks when exceptions are thrown. When an exception is thrown, you don't want any objects that are allocated earlier in the try block to be leaked. By wrapping them in smart pointers, which will be destroyed when the try block is exited, those objects will get properly destroyed.
• Manage lifetime by reference counting owners to objects (i.e., the last one to destroy its smart pointer referencing a particular object actually deallocates the object). This is especially helpful in loosely coupled scenarios where it is not clear at what time the object should be destroyed, because users of the object do not know about each other.

A good example of where smart pointers are useful:

A vector of pointers to objects. By
making it a vector of shared pointers,
for example, the objects will
automatically be deallocated when the
vector is destroyed and/or objects are
removed. This automates object lifetime management and helps the user of the container avoid memory leaks.

Mixing boost smart pointers and C++11 smart pointers in boost::signals2

I found a solution, and it was to use .track_foreign instead of .track. It allows the use of C++11 smart pointers in place of the boost smart pointers.

OpenCV or Boost smart pointers

For what I can see in OpenCV documentation, this is a reference-counted smart pointer, essentially, same as boost::shared_ptr. Even it uses atomic operations on the reference count.

I would make the choice based on portability and interoperability.

1. Is your system going to be ported elsewhere and depends on OpenCV for sure but not on boost?
   Then, stick to OpenCV cv::Ptr if you can avoid boost and you get rid of the dependency.

2. Does boost::shared_ptr plays nice with the rest of OpenCV?
   If you have something returning a cv::Ptr from OpenCV library, maybe it's better to stick to cv::Ptr in these cases, because the reference count will be handled incorrectly if you mix both kind of pointers and the resource could be destroyed prematurely.

3. You're going to stick to boost wherever you port the project?
   Then, stick to boost::shared_ptr when you can do it, it's more standard, people know it and will immediately understand your code. UPDATE: In C++11 you have std::shared_ptr, which amounts to no dependency if you can afford it, so you can use std::shared_ptr in this case and get rid of boost also.

Just as a side note, there is a technique to mix boost and std shared pointers that can keep the reference correctly around and could be useful for someone. See this question, it could be relevant also for mixing other kind of reference-counted pointers: Conversion from boost::shared_ptr to std::shared_ptr?

In my experience, when you port something, the fewer dependencies, the better, or there are certain platforms for which compiling can be a hell. So make your choice based on portability if it's a concern and interoperability of pointers with libraries.

Simple boost smart pointer syntax issue

My mythical glass orb of magic debugging tells me you're doing something like this:

class X{
  boost::shared_ptr<cPreFilterProcess> preProcess;
public:
  X(){
    preProcess(new cPreFilterProcess(pars));
  }
};

You need to use either the member initializer like:

X() : preProcess(...){}

Or use .reset since your can't just assign a pointer like that:

X() { preProcess.reset(...); }

I would strongly recommend the first option though.

---

Related Topics