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

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

"Howard Hinnant" <hinnant_at_[hidden]> wrote in message 
news:09BEB9D2-D48D-11D6-825B-003065D18932_at_twcny.rr.com...

>> And whatever that smart pointer is called, I think:
>>
>>      initialize(std::auto_ptr<X>& p) {
>>          px_.reset(p.release());
>>      }
>>
>> is much preferred since it explicitly says what is happening, and
>> decouples typeof(px_) from std::auto_ptr.
>>
>> Sometimes less is more.

On Monday, September 30, 2002, at 12:13  PM, Ed Brey wrote:

> I infer from this that you would then be in favor of dropping the 
> auto_ptr overload on the constructor.

Yes, that is a fair statement (and dropping reset too).  Although I 
should qualify this statement with one of backward compatibility and 
migration.  We can't do what I suggest until there has been an 
alternative smart pointer available for some period of time.

> I partially understand the appeal of keeping the semantics narrow, 
> although only if applied with complete consistency to all methods.

Agreed, consistency is very important.

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

The main motivation for scoped_ptr seems to be as local auto variable 
in a function.  If scoped_ptr has no transfer semantics, then the 
reader of such a function knows immediately what the role of this 
smart_ptr is within that function.  There is no need to read further to 
find out if ownership is going to be transferred out of the function.

> A related question is how does adding the word release make the 
> example any clearer, unless you would also do the same when 
> transfering to shared_ptr?

I'm all for consistency! :-)  Imho, transferring resources with syntax 
that looks like copy semantics is a bad idea, no matter what the name 
of the classes involved.  Given some generic code:

T t;
...
U u(t);

This looks like copy.  Sometimes it is not.  Imo when it is not copy, 
it is suboptimal code.  I think it would be better to do:

T t;
...
U u(t.release());

Or perhaps some other syntax to signify that t is being pilfered and 
not copied.

Moving resources with copy syntax can lead to difficult-to-detect run 
time errors in generic code. This is best prevented by not creating 
concrete types that move with copy syntax (which may some day be put 
into generic code which subtly expects copy semantics).

-Howard