On Apr 30, 1:04 pm, Scott Meyers <NeverR...@aristeia.com> wrote:
I've asked a lot of questions about C++0x recently, so let me emphasize that I'm asking about current C++ (C++03) here.
Consider:
Widget *pwa = new Widget[100];
...
delete [] pwa;
Suppose that the destructor for pwa[50] throws. What happens next? 15.1
tells me that "control is transferred to the nearest handler with a
matching type," but 5.3.5/6 tells me that in a delete expression for an
array, "the elements will be destroyed in order of decreasing address (that
is, in reverse order of the completion of their constructor." So are
destructors invoked for array elements 0-49?
My sense is that when pwa[50]'s destructor throws, the delete expression is
essentially abandoned (much as a looping expression would be abandoned if
an exception occurred during iteration), elements 0-49 of the array are not
destroyed, and the memory occupied by the array is not reclaimed by
operator delete (because that would have been performed by the
now-abandoned part of the delete expression), but I'd like to have more to
go on than how I sense things. So is the behavior of the above spelled out
by the standard?
"Doctor, it hurts when I poke myself in the eye!" much?
I don't know if it's spelled out in the standard, but I would be
HUGELY surprised if any compiler's generated code would continue to
call dtors etc after an exception was thrown. That would essentially
mean that operator delete[] is (warning: compiled with head-compiler
and tried with head-debugger):
template<typename TYPE>
void OperatorArrayDelete(TYPE* pBegin)
{
TYPE* pEnd = pBegin+ElementCount(pBegin);
while (pEnd!= pBegin)
try { (*--pEnd)->~Type(); } catch(...) {}
// Well, that catch(...) {} smells to high heaven!
SomehowFreeHeap(pBegin);
}
15.1.must take precedence over 5.3.5/6. It must!!! Aaaaaarghhhhh! :-)
Goran.
what it then does. IMHO if you get an unexpected exception in a
member functions to avoid exceptions there. Getting it right is easier