Smart pointer status, directions, thoughts

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 
practice.

*  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 
desired.

--Beman

Reference: Andrei Alexandrescu, Modern C++ Design, ISBN 0-201-70431-5.  The 
code (including his SmartPtr) is available at 
http://www.awl.com/cseng/titles/0-201-70431-5/loki.zip

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.