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

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2002-09-30 10:55:27

On Monday, September 30, 2002, at 11:32  AM, Ed Brey wrote:

> Here is the equivalent motivating example for the reset overload:
>
> struct A {
>     scoped_ptr<X> px_;
>
>     initialize(std::auto_ptr<X>& p) {
>         px_.reset(p);
>     }
> };
>
> The argument for why the member variable should be a scoped_ptr 
> (versus an auto_ptr) is the same as the argument for why the automatic 
> variable is a scoped_ptr in your example.
>
> The thought of an operator= on scoped_ptr that takes an auto_ptr is an 
> interesting one.  Given that its constructor takes an auto_ptr, one 
> could say that scoped_ptr will "transfer in a pointer", but will not 
> "transfer out a pointer".  Given that definition of scope, an 
> assignment operator that transfers in a pointer seems necessary for 
> completeness.

On Tuesday, September 24, 2002, at 07:51  PM, Beman Dawes wrote:

> Me too. I'm a big fan of scoped_ptr. Making it "more powerful" will 
> make it less useful.

On Tuesday, September 24, 2002, at 08:06  PM, Greg Colvin wrote:

> Yep.  I don't even like it having reset.

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.

-Howard