"David B. Held" <[EMAIL PROTECTED]> writes:
> "David Abrahams" <[EMAIL PROTECTED]> wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
>> [...]
>> "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
[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
