Björn Karlsson - Beyond the C++ Standard Library: An Introduction to Boost

• Automatic lifetime management of objects with shared_ptr makes shared ownership of resources effective and safe.

• Safe observation of shared resources through weak_ptr avoids dangling pointers.

• Scoped resources using scoped_ptr and scoped_array make the code easier to write and maintain, and helps in writing exception-safe code.

Smart pointers solve the problem of managing the lifetime of resources (typically dynamically allocated objects

[1] Just about any type of resource can be handled by a generic smart pointer type.

This chapter has introduced the Boost smart pointers, a contribution to the C++ community that can hardly be overestimated. For a smart pointer library to be successful, it must take into consideration and correctly handle a great number of factors. I'm sure you have seen quite a number of smart pointers, and you might have even been involved in their creation, so you are aware of the effort involved to get things right. Not many smart pointers are as smart as they should be, and that makes the value of a proven library such as Boost.Smart_ptr immense.

Being such a central component of software engineering, the smart pointers in Boost have obviously received a lot of attention and thorough review. It is therefore hard to give credit to all who deserve it. Many have contributed valuable opinions and have been part of shaping the current smart pointer library. However, a few exceptional people and efforts must be mentioned here:

• Greg Colvin, the father of auto_ptr , also suggested counted_ptr , which later became what we now call shared_ptr .

• Beman Dawes revived the discussion about smart pointers and proposed that the original semantics as suggested by Greg Colvin be considered.

• Peter Dimov redesigned the smart pointer classes, adding thread safety, intrusive_ptr , and weak_ptr .

It is intriguing that such a well-known concept continues to evolve. There will undoubtedly be more progress in the domain of smart pointers or maybe, smart resources, but just as important is the quality of smart pointers that are used today . It's survival of the fittest, and that's why people are using Smart_ptr. The Boost smart pointers are a fine, assorted selection of delicious software chocolate, and I eat them regularly (you should, too). We'll soon see some of them become part of the C++ Standard Library, as they have been accepted into the Library Technical Report.

There are three typical scenarios when smart pointers are appropriate:

• Shared ownership of resources

• When writing exception-safe code

• Avoiding common errors, such as resource leaks

Shared ownership is the case when two or more objects must use a third object. How (or rather when) should that third object be deallocated? To be sure that the timing of deallocation is right, every object referring to the shared resource would have to know about each other to be able to correctly time the release of that resource. That coupling is not viable from a design or a maintenance point of view. The better approach is for the owners to delegate responsibility for lifetime management to a smart pointer. When no more shared owners exist, the smart pointer can safely free the resource.

Exception safety at its simplest means not leaking resources and preserving program invariants when an exception is thrown. When an object is dynamically allocated, it won't be deleted when an exception is thrown. As the stack unwinds and the pointer goes out of scope, the resource is possibly lost until the program is terminated (and even resource reclamation upon termination isn't guaranteed by the language). Not only can the program run out of resources due to memory leaks, but the program state can easily become corrupt. Smart pointers can automatically release those resources for you, even in the face of exceptions.

Avoiding common errors. Forgetting to call delete is the oldest mistake in the book (at least in this book). A smart pointer doesn't care about the control paths in a program; it only cares about deleting a pointed-to object at the end of its lifetime. Using a smart pointer eliminates your need to keep track of when to delete objects. Also, smart pointers can hide the deallocation details, so that clients don't need to know whether to call delete , some special cleanup function, or not delete the resource at all.

Safe and efficient smart pointers are vital weapons in the programmer's arsenal. Although the C++ Standard Library offers std::auto_ptr , that's not nearly enough to fulfill our smart pointer needs. For example, auto_ptr s cannot be used as elements of STL containers. The Boost smart pointer classes fill a gap currently left open by the Standard.

The main focus of this chapter is on . Although the complementary scoped_array and shared_array are sometimes useful, they are not used nearly as frequently, and they are so similar to those covered that it would be too repetitive to cover them at the same level of detail.

The Smart_ptr library has been proposed for inclusion in the Standard Library, and there are primarily three reasons for this:

• The Standard Library currently offers only auto_ptr , which is but one type of smart pointer, covering only one part of the smart pointer spectrum. shared_ptr offers different, arguably even more important, functionality.

• The Boost smart pointers are specifically designed to work well with, and be a natural extension to, the Standard Library. For example, before shared_ptr , there were no standard smart pointers that could be used as elements in containers.

• Real-world programmers have proven these smart pointer classes through heavy use in their own programs for a long time.

The preceding reasons make the Smart_ptr library a very useful addition to the C++ Standard Library. Boost.Smart_ptr's shared_ptr (and the accompanying helper enable_shared_from_this ) and weak_ptr have been accepted for the upcoming Library Technical Report.

boost::scoped_ptr is used to ensure the proper deletion of a dynamically allocated object. scoped_ptr has similar characteristics to std::auto_ptr , with the important difference that it doesn't transfer ownership the way an auto_ptr does. In fact, a scoped_ptr cannot be copied or assigned at all! A scoped_ptr assumes ownership of the resource to which it points, and never accidentally surrenders that ownership. This property of scoped_ptr improves expressiveness in our code, as we can select the smart pointer ( scoped_ptr or auto_ptr ) that best fits our needs.