Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-05-23 10:04:15

Greg Colvin, Kevlin Henney, and I discussed smart pointer "big-picture"
issues at the recent C++ committee meeting. We touched on the state of the
current Boost smart pointers, various designs and experiments all three of
us have been considering, and the work of various other people.

What follows is my take on smart pointer status, directions, and thoughts;
it goes a bit beyond the discussion with Greg and Kevlin, so they may
disagree with parts of it.

* The current Boost smart_ptr.hpp classes (together with std::auto_ptr)
are mature, well-known, and continue to be the best and safest
recommendation for most everyday smart pointer needs. They should be
proposed for standardization. They are not the best hope for the ultimate
smart pointer, however, and should not be extended via additional
parameters to try to turn them into something they just aren't.

* It might be useful to add an additional Boost smart point class which
could handle cyclic data structures. The context would be adding to the
scoped_ptr/auto_ptr/shared_ptr family, not doing something totally
unrelated. Interface should follow scoped_ptr/auto_ptr/shared_ptr

* Design investigations of ultimate or at least improved smart pointers
should continue to be encouraged. In addition to the lines of development
that Boost developers have been following, the policy based approach
advocated by Andrei Alexandrescu is quite interesting (see below).

* The policy based approach and the generator approach may not be mutually
exclusive. It may be possible to write a smart pointer generator which
generates the appropriate policy based smart pointer type. The aim would
be ease of use (using the generator) for most applications, with the policy
based smart pointer as a fall-back where non-generated customization is


Reference: Andrei Alexandrescu, Modern C++ Design, ISBN 0-201-70431-5. The
code (including his SmartPtr) is available at

Summary: A policy class is essentially a generic programming version of a
mixin. It differs from a traits class in that it provides visible
interfaces, not just internal implementation details. By composing a
framework class template like SmartPtr almost entirely of policy classes,
tremendous flexibility results. Template template parameters ease some but
not all of the template parameter pain. Library supplied policy classes
meet common needs, while users can supply their own to meet uncommon needs.

Boost list run by bdawes at, gregod at, cpdaniel at, john at