"David B. Held" <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
