Boost logo

Boost :

From: Kevlin Henney (Kevlin.Henney_at_[hidden])
Date: 1999-07-13 12:06:42


Beman wrote:

Two thoughts:

Auto_ptr got into so much trouble by adding an apparently simple
feature to a very simple class. This experience makes me very wary
of trying to add features to smart pointers.

   I would tend to disagree: auto_ptr got broken because simplistic
   features were added to it -- in terms of design, they introduced more
   problems than they solved. That this was (and is) the case is simple to
   demonstrate, which begs the question of why that design went off the
   rails in the first place (that was rhetorical >:->).

There are an apparently endless number of smart pointers. John Max
Skaller has identified something like 36, each with its own feature
set, and I don't think he even touched on some of your ideas. If
there are too many flavors in a library, people become confused and
don't use any of them.

   Yes, indeed there are many kinds of smart pointer (I have not identified
   as many as John, but the fact that they are useful should not stop
   people using them), but they are clearly separated by intent. For
   instance, there is a common misunderstanding that "smart pointer" ==
   "memory management", which is clearly not the case. The smart pointer
   idiom can be used in support of a number of proxy access models, such as
   remoting, locking, etc. The route to confusion is to group them all
   together under the heading of smart ptr, ie coincidental cohesion.

   However, returning to the point, the idea of adding a nocount is not
   really adding a new type of smart ptr at all. It simply allows more
   flexible use of the library. The introduction of a shared count for 1
   allows a simple optimisation for a common case, and a resolution of the
   construction problem (ctors would then never fail).

   Thoughts?

   Kevlin

------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk