Re: [boost] scoped_ptr rationale

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-09-20 20:37:30

On Friday, September 20, 2002, at 07:24  PM, David Abrahams wrote:

> The more I think about scoped_ptr the harder it gets to justify using  
> it.
> It still has explicit transfer-of-ownership via reset(), though  
> there's no
> implicit transfer-of-ownership. In some sense, std::auto_ptr<T> const  
> is a
> better candidate for the role that I've always thought scoped_ptr was
> playing, since there is no reset() member. The case where you need to
> default construct a smart pointer and later initialize it is enough of  
> a
> corner that I'd be inclined to recommend a straight-up auto_ptr for  
> that. I
> guess the only downside to auto_ptr for that role is the
> automatically-generated copy constructor and assignment operator. When  
> we
> get move_ptr
> (http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/papers/2002/ 
> n1377.htm#move_ptr%
> 20Example) we'll be all set ;-)

I can see several useful smart pointers here (though I do not yet know  
their names):

1.  no copy semantics, no move semantics.
scoped_ptr without a reset, or as you note const auto_ptr could satisfy  
this.

2.  move semantics, no copy semantics.
move_ptr.

3.  copy semantics, no move semantics.
shared_ptr, and/or a deep-copy "clone ptr" could fill this role.

4.  copy semantics, move semantics.
Same as #3.  Once you have copy semantics, move semantics is just an  
optimization.  It should not effect interface.

Imho, if/when move_ptr becomes a reality, auto_ptr is fatally flawed  
because of the "moves with copy syntax" behavior.  At that point  
scoped_ptr could still have an advantage over move_ptr if it said:  
"this smart pointer *will_not* transfer ownership."  i.e. scoped_ptr  
might have to jettison reset.  Otoh, const scoped_ptr, const move_ptr,  
and const auto_ptr all have #1 semantics.

> Well, OK, there's the "deletion of incomplete type" issue (use of
> checked_delete) which is also not provided by auto_ptr.

If I'm not mistaken, this issue is orthogonal to the ownership issue.   
Could this technology not be integrated into any smart pointer with no  
run time or space overhead?

hmm...  Definitely a subject worthy of ruminations! :-)

-Howard