|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk