35dd40f8
From: dave@boostpro.com
on Tue Jun 26 2012, Rani Sharoni wrote:
> On Jun 24, 8:30 pm, Dave Abrahams wrote:
>> on Sun Jun 24 2012, Rani Sharoni wrote:
>> > Will the following memory be freed if the dtor of 'A' throws:
>> > delete pA; // pA is of type A for which ~A might throw
>>
>> > I'm not sure what the standard says about such... (hence how the
>> > implementation of given smart-ptr should 'safely' handle such).
>>
>> I don't know for sure either, but the answer has to be "yes" (and if
>> it isn't, that must be fixed). The lifetime of *pA has ended, so
>> there's absolutely no reason to keep the memory around.
>
> You are right. shortly after posting I saw that the text address this:
> 5.3.5/7 - [ Note: The deallocation function is called regardless of
> whether the destructor for the object or some element of the array
> throws an exception. —end note ]
>
> (thanks Danial for the reference).
>
> We can try to generalize this principle:
> Destructor never fails to end the lifetime of the destroyed objects.
> Throwing destructor should not result with resource leak or bugs.
>
> Conclusion - the success of the destructor to properly end the
> lifetime of an object should not be dependent on operations that might
> fail (I have seen few win32 functions that doesn't respect this).
>
> It's seems easy to apply such principle to operations like
> container::pop() but it's less clear how to apply it to operations
> like container::clear(). should the exception abort the cleanup of the
> rest of the operations?
Unspecified. clear() would be a basic guarantee operation.
> if so then how ~container() should be handled as it has to end the
> lifetime of the contained objects to avoid leak (since it's about to
> die). Should the destruction continue after the exception?
Yes.
> what if there is another exception thrown by the next element? should
> throwing dtor always check that it's not during unwinding?
No.
> Maybe this should be tackled using the built-in array destruction
> rules.
The rules should be the same.
> The "object must die" principle is also problematic for functions like
> POSIX close(). AFAIR there are some cases in which the file-handle is
> still alive after close() failure (e.g. POSIX cancellation might abort
> close()).
If it's problematic, you don't have to throw.
> In other cases, like networking breakdown when closing the
> file-handle, close() might return error but nevertheless guarantee
> that the object lifetime ended (i.e. local resources freed). In that
> sense "remote cleanup" is such problem in general. C++ destruction is
> obviously not hospitable for such behaviors.
I don't see why not. What else can be done?
> I personally hate the thought of having throwing destructors as a
> common construct like throwing ctor.
I dislike it also, but that's not a good enough reason to make whole
programs brittle if there's an exception in a dtor, IMO.
> It can simply break to much cleanup code that assumes that dtors do
> NOT throw and might force new dtos code to be written in some ugly
> fashion to assure that all of its explicit code is being executed
> regardless of exceptions.
I disagree that this is an issue. The "ugly" rewrite could consist
of refactoring cleanups into subobjects, which is usually a pretty
attractive solution.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
