|
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