Re: [boost] Proposal about smart_ptr

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2001-10-21 11:00:27

From: Peter Dimov <pdimov_at_[hidden]>
> From: "Greg Colvin" <gcolvin_at_[hidden]>
> > 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.
> 
> Yes, this makes sense. But in our case neither copy construction nor
> assignment are defined this way, since shared_ptr has no release() member.

Makes sense to me.

> > 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'm not that concerned about reset() errors; it's simply that making it
> handle self-resets complicates both the precondition and the postcondition,
> introducing a special case. It simply feels wrong, and doesn't buy us
> anything.
> 
> In this case it complicates the specification instead of simplifying it. :-)

I'm sold then.  Thanks.

> > 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.
> 
> One thing we need to decide is whether shared_ptr should handle 'finalizers'
> or not. Note that this doesn't affect shared_count, only the shared_ptr
> interface.

Yes, it should.  I'm just not sure we have the right interface, but
that is part of what a Boost review is for.

> For compilers that don't support member templates, I suggest that we
> introduce a separate header (the convention is usually ob_shared_ptr.hpp,)
> perhaps avaiable only through smart_ptr.hpp. This will make the code
> considerably easier to read, since most of it is #ifdef-ed on this feature
> (and I know that some programmers refuse to use shared_ptr because "the code
> is too ugly.")
> 
> This 'compatibility' header will simply be a (possibly cleaned-up) version
> of the current code and will not make use of shared_count.

This sounds like a clean way to arrange things.

> > 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.
> 
> This is a very thorny issue. In my opinion neither operator< nor std::less
> (which was originally devised as a function object version of operator<, no
> more) is the "proper" ordering primitive. At the same time, I accept that
> the current STL uses operator< (only; no >, <=, >=) for ordering and am
> quite willing to define one when I need a type to be ordered. For instance,
> my std::type_info* wrapper has operator<.
> 
> What convinced me that operator< is the right ordering primitive (in the
> context of the current standard library design) was that I needed to make a
> 
> std::map<std::pair<typeinfo, typeinfo>, ...>
> 
> and a specialized std::less doesn't work here, while an operator< does. This
> is not limited to std::pair, by the way; containers, as per table 65, also
> have a 'proper' operator<, but no less<> specialization.
>
> In any event, if we really have to reinvent the ordering primitive, I
> suggest we _not_ name it boost::less (boost::before maybe.)
> 
> And of course, as a MSVC user, I prefer something that works over something
> that doesn't work. I realize that this is not a very strong argument by
> itself. :-)

As I said, I can accept operator< as a stopgap until the committee comes
up with something better.  If nothing better is found, then operator< will
have to do.  But the full compliment is overkill.