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

From: Ed Brey (brey_at_[hidden])
Date: 2002-09-30 13:47:25

"Howard Hinnant" <hinnant_at_[hidden]> wrote in message news:3FF54DAB-D496-11D6-825B-003065D18932_at_twcny.rr.com...
> 
> > The one point that I am struggling to grasp is how having no transfer 
> > semantics is better than having only transfer in semantics.  Given 
> > that the new expression for the pointee is outside of scoped_ptr, in 
> > reality it *needs* transfer in semantics.  Given that they exist, how 
> > is it better to restrict them than to make it general feature?
> 
> Agree 100% that you need transfer semantics for this application.  I 
> think we need another smart pointer.  From the scoped_ptr documentation:
> 
> > The scoped_ptr template is a simple solution for simple needs. It 
> > supplies a basic "resource acquisition is initialization" facility, 
> > without shared-ownership or transfer-of-ownership semantics. Both its 
> > name and enforcement of semantics (by being noncopyable) signal its 
> > intent to retain ownership solely within the current scope. Because it 
> > is noncopyable, it is safer than shared_ptr or std::auto_ptr for 
> > pointers which should not be copied.

My contention is that not only are transfer semantics needed for the particular application we were discussing, but that transfer semantics are needed for *any* application.  In RAII, the "acquisition" is performed by a transfer.  If we moved to a smart pointer that constructed the pointee itself (with support for up to n arguments in which would be passed through to an internal new expression, etc.), then scoped_ptr could truely live without transfer semantics.  However, as it is, we have transfer semantics, whether we like it or not.

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.

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.)