Re: Behavior of array deletion if an element's dtor throws
On 11 May, 18:22, Scott Meyers <NeverR...@aristeia.com> wrote:
Nikolay Ivchenkov wrote:
On 30 Apr, 15:04, 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?
According to 15.2/2:
"An object that is partially constructed or partially destroyed will
have destructors executed for all of its fully constructed subobjects,
that is, for subobjects for which the constructor has completed
execution and the destructor has not yet begun execution."
[...]
When the destructor for pwa[50] throws, the entire array is partially
destroyed by the delete-expression and, according to 15.2/2,
destructors shall be executed for all of its subobjects for which the
destructor has not yet begun execution.
Except that 15.2/1 makes clear that section 15.2 pertains only to automatic
objects
I don't understand your conclusion. I think that 15.2/2 applies to
objects created by new-expressions as well. However, it is unclear
what should happen if the destructor called for a subobject of an
object with static storage duration throws:
#include <iostream>
struct A1
{
A1() { std::cout << "A1()" << std::endl; }
~A1() { std::cout << "~A1()" << std::endl; }
};
struct A2
{
A2() { std::cout << "A2()" << std::endl; }
~A2()
{
std::cout << "~A2()" << std::endl;
throw 0;
}
};
struct X
{
A1 a1;
A2 a2;
};
X x;
// shall x.a1 be destroyed before
// the program termination?
int main()
{
try
{
x.~X();
// shall C++03 - 15.5.1/1 bullet 4
// be applied here?
}
catch (int)
{
std::cout << "catched" << std::endl;
}
new (&x) X;
}
Even if it did, there would have to be a way to resolve the apparent
contradiction with 15.2/1, which says that throwing an exception transfers
control to a handler.
I believe that the wording "When an exception is thrown, control is
transferred to the nearest handler with a matching type" is
incorrectly formulated since there are several cases when the control
never reaches any handler as a result of throwing an exception:
- when std::terminate is called under circumstances described in
15.5.1/1;
- when during stack unwinding any function calls std::abort or
std::exit;
- when during stack unwinding any function executes an infinite loop.
Actually, when an exception is thrown, the control may be immediately
transferred to:
- the copy constructor corresponding to the exception object, or
- the destructor for a recently constructed object, or
- the std::terminate function, or
- the std::unexpected function, or
- the nearest handler with a matching type.
Though 15.2 and 15.5 partially clarify the original intention, I think
that such style of description is definitely inappropriate for the
international standard. In other words, we have a fundamental defect
in the description of the exception handling mechanism. But I don't
think that the situation with array destruction is particularly
interesting in this respect.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]