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