[boost] Re: Re: scoped_ptr::reset and auto_ptr

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-09-30 15:46:12

On Monday, September 30, 2002, at 02:47  PM, Ed Brey wrote:

> That is not to say that we cannot qualifiy scoped_ptr at all.  Its 
> transfer semantics are limited to "transfer in", which differentiates 
> it greatly from auto_ptr.  I submit that this by far the less 
> dangerous of the two directions, and so need not concern us greatly.

Agreed, as long as it is safe to transfer out of the source, and it is 
clear that a transfer is taking place.

> To me the question is, given that we have to live with transfer in, 
> how do we define its details?  My answer would be to allow anything 
> tends not to be error prone.  Clearly, we don't allow operator=(T*).  
> IMHO, given the semantics and purpose of auto_ptr, an overload for it 
> is OK.  By using auto_ptr in the first place, the user has already 
> jumped into move-via-copy-syntax land, because such is the nature of 
> auto_ptr, and scoped_ptr's job is not to change auto_ptr's nature.  (A 
> viable alternative is the view that auto_ptr only applies 
> move-via-copy-syntax when used with itself, in which case no other 
> class should interoprate with it.)

This is all certainly ok.  I guess I've just grown leery of auto_ptr 
(after being a big fan of it) and have started to shun 
move-via-copy-syntax.  Maybe it is just a phase I'm going through. ;-)

I'm also gun shy of adding more capability to scoped_ptr.  auto_ptr 
started out simple too but grew to meet more and more demands.  At some 
point you've got to say:  stop, that functionality belongs in a 
separate class.  Not saying we've crossed that line with scoped_ptr or 
auto_ptr.  Just saying that line is out there somewhere, and we should 
be careful of crossing it.  Maybe just discussing the existence of such 
a boundary is sufficient for now.

-Howard