Re: [boost] Proposal about smart_ptr

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-10-20 22:24:46

I just got home to 282 emails, many about smart_ptr.  I'm glad the little bug report stimulated such a productive conversation.  I
won't be in Redmond (although I am hoping I can join in by phone)
so here are my thoughts.

I am basically in favor of Peter's design, except that I would
prefer that reset() be defined as it is for auto_ptr, unless it
truly damages the implementation.  The std::auto_ptr is designed
the way it is for simplicity of specification.  Copy construction
and assignment are defined as reset(a.release()), so reset() has
to handle self-assignment properly.  Perhaps this makes reset() a 
little more error prone, but I consider reset(), release(), and
get() to be unfortunate historical accidents that should be used
as little as possible.

I am also very much in favor of the shared_count design, but I am
not sure we have the interface nailed down.  So it would seem
appropriate to put it in a details namespace for now, and compile
in the associated constructors conditionally until we get enough experience to be sure we have it right.

As for operator<, I still believe it is fundamentally wrong for
a pointer type.  I can accept it as a stopgap until the committee
can work out the issues with std::less, but I'd prefer not to
commit to the entire set of comparisons.  I would like to see a
boost::less (and boost::swap) that do the right thing for our
smart pointers.

In my opinion these are small caveats to Peter's work.  So I think
it is time for Beman and I to help Peter draft a proper proposal
to submit for a thorough review.