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

From: Ed Brey (brey_at_[hidden])
Date: 2002-09-30 15:34:05

"David Abrahams" <dave_at_[hidden]> wrote in message news:100001c268b1$f56e6cb0$6501a8c0_at_boostconsulting.com...
> From: "Ed Brey" <brey_at_[hidden]>
> 
> > My contention is that not only are transfer semantics needed for the
> particular application we were discussing, but that transfer semantics are
> needed for *any* application.  In RAII, the "acquisition" is performed by a
> transfer.
> 
> 
> Oh, please!
> RAII has never been well-defined and there's nothing in its name which
> implies the acquisition is done by transfer-of-ownership. In fact, if you
> believe there's some power in the name, it's easy to interpret this as
> RAII:
> 
>     struct foo
>     {
>         struct body;
>         foo() : b(new body) {} // <===
>         ~foo() { delete body; }
>         body* b;
>     };

I didn't mean to imply that RAII necessarily involves transfer of ownership - just that scoped_ptr does.  And so using scoped_ptr to implement a RAII concept involves a transfer of ownership, or at least syntax that is indistinguishable from a usage that would involve such transfer.

That is to say

scoped_ptr<X> px(create_object()); // RAII

looks identical in syntax to 

scoped_ptr<X> px(transfer_existing_object()); // Transfer-of-ownership

Short of banning the user from creating or transferring objects via dump pointers, there is nothing we can do about this.  To solve the problem we would need something like this:

scoped_ptr<X> px; // Creates X.
// px has acquired X by initializing it.

Of course, this isn't known to be viable due to the constructor-argument forwarding problems.

In any case, don't get hung up on my (nonnormative) reference to RAII.  I only mentioned it for additional clarity, which it obviously didn't provide. :-)

Digging-out-of-the-holy-yours,
Ed