Re: [boost] Re: SmartPtr (Loki) - auto_ptr/move c'tor issue

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-31 16:44:21

"David B. Held" <dheld_at_[hidden]> writes:

>> In principle you don't have to promise to delete the unmanaged
>> resource if your constructor throws; it's just your desire to be
>> usable with "new T" that makes it neccessary.
>
> Ok, I think I get it.  Whereas, if a policy were to throw, and leak an
> internally allocated count, then the c'tor does not even provide the
> basic guarantee?

Right.

>> In fact, I have been arguing for years that our smart pointers should
>> never have had a public interface which adopts unmanaged resources
>>on construction.  Instead, we should write:
>>
>>      std::auto_ptr<T> = std::auto_ptr_new<T>(arg1, arg2, arg3);
>>
>> Voila, a managed T straight out of the box.
>
> It might be nice if you assigned it to a variable. ;>

Some people are never satisfied ;>

>> However, the desire to subsume existing smart pointers means you
>>have to support the unsafe "unmanaged adoption interface."
>
> Maybe we can eat our cake and have it too.

If eating the cake means "not having to support unmanaged adoption", I
don't think so ;-)

>> [...]
>> The move proposal says that standard components will require
>> the move construct/assign of their UDT parameters, if any, to be
>> nothrow.  In practice that would be needed by any generic
>> components.  That's enough to make the move undo-able.
>
> Ok, but that still leaves smart_ptr with a few tricks to pull off.  Let's
> look at smart_ptr(std::auto_ptr p) for a minute:
>
> smart_ptr(std::auto_ptr<U>& p)
>     : storage(p), ownership(p), checking(), conversion()
> { checking::on_init(p); }
>
> Now, the first that happens is that storage(p) attempts to take
> ownership of p.  

p is an auto_ptr<U>&, so how is that ever going to happen?

> For default storage, this is a no-throw operation.  Let's say we're
> moving p into a counted pointer.  Now ownership has to allocate a
> count, and might throw in the process.  If it does, we either have
> to clean up p, or we have to stuff the toothpaste back into the
> tube.

Both highly imprecise notions; I don't know what either means for sure
in this context.

> I see that shared_ptr solves this by violating RAII.  

I don't know what this means either.  RAII is not something you can
"violate".  It's a technique or idiom.

No time to look at the rest of this right now...
-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution