Boost logo

Boost :

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

is much preferred since it explicitly says what is happening, and
decouples typeof(px_) from std::auto_ptr.

Sometimes less is more.


Boost list run by bdawes at, gregod at, cpdaniel at, john at