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

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

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

> I'll add my voice in support of a simpler scoped_ptr with no transfer 
> semantics at all.  I see the motivation for a smart pointer as Ed and 
> others need.  I just don't think it should be named scoped_ptr.
> 
> 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.

I infer from this that you would then be in favor of dropping the auto_ptr overload on the constructor.  I partially understand the appeal of keeping the semantics narrow, although only if applied with complete consistency to all methods.

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?

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?