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

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-29 15:08:48

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

> "David Abrahams" <dave_at_[hidden]> wrote in message
> news:usmvbrcxi.fsf_at_boost-consulting.com...
>> [...]
>> "They" meaning function-try-blocks?
>
> Yes.
>
>> The rule I have stuck in my head from the last time I considered this
>> was: all they give you is the ability to translate the exception into
>> some other exception.  I never thought that was a particularly
>> valuable thing to do in most cases.
>
> So I've heard.
>
>> [...]
>> > which is quite too often.  Namely, it doesn't know when it
>> > *shouldn't* free the resource, because it doesn't know about
>> > Ownership.  So now it looks like we're back to that pesky function
>> > try-block, and requiring StoragePolicy to be no-throw. :(
>>
>> I can't agree with your conclusion.  IMO the right answer is that
>> StoragePolicy promises to free the resource it's initialized with when
>> construction fails.
>
> Unfortunately, StoragePolicy doesn't know when other c'tors have
> failed.  The only one who does is smart_ptr, which is why it seems
> I have to either A) use a function try block to inform StoragePolicy
> that someone else has failed, and clean up appropriately, 

Why not just arrange for StoragePolicy to be the first constructed?

> or B) not use initializer lists, and do all the work in the c'tor
> body of smart_ptr.  

I don't see how B can work; the resource will be unmanaged at least
until the body is entered, while all the bases and members are
constructed.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution