Re: Behavior of array deletion if an element's dtor throws
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."
The specification does not provide the definitions for "partially
constructed object" and "partially destroyed object" (IMO, they shall
be provided). Lets assume that "partially destroyed object" is defined
as follows:
An object is said to be partially destroyed when its destruction has
started and not completed. The destruction of a non-array object with
non-trivial destructor implies the execution of its destructor. The
destruction of an array object implies the destruction of all its
elements.
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. Note: VC++ 9.0 and Intel C++
11.0.061 follow these rules, but GNU C++ 4.5 don't.
However, I don't see any rule that would require the execution of the
deallocation function in this case. Note that the following rule is
irrelevant:
"If the object or array was allocated in a new-expression, the
matching deallocation function (3.7.3.2, 5.3.4, 12.5), if any, is
called to free the storage occupied by the object."
Widget *p = new Widget;
// the object was allocated in a new-expression;
// if the constructor throws, the deallocation function is called
// to free the storage occupied by the object
p->~Widget();
// if the destructor throws, the deallocation function is not
called
// to free the storage occupied by the object
new(p) Widget;
delete p;
// if the destructor throws, the deallocation function is not
called
// to free the storage occupied by the object
On 3 May, 17:01, Daniel Krugler <daniel.krueg...@googlemail.com>
wrote:
On 30 Apr., 13:04, Scott Meyers <NeverR...@aristeia.com> wrote:
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),
This is incorrect, the deallocation is required to be called,
see 5.3.5 [expr.delete]/7:
"The delete-expression will call a deallocation
function (3.7.3.2)."
Do you want to say that the deallocation function is required to be
called even if the destructor calls std::abort or std::exit?
#include <cstdio>
#include <cstdlib>
struct X
{
void operator delete[](void *p) throw()
{
std::printf("operator delete[]\n");
::operator delete[](p);
}
~X()
{
std::printf("~X()\n");
std::exit(0);
}
};
int main()
{
delete[] new X[2]; // ?
}
Secondarily, is the behavior specified by C++0x any different?
No, it is not different, but the wording has been
improved a bit as part of resolving issue
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#353
to make especially 5.3.5/7 clearer by adding
the note:
"[ 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 ]"
This note violates ISO/IEC Directives, Part 2 - 6.5.1:
"Notes and examples integrated in the text of a document shall only be
used for giving additional information intended to assist the
understanding or use of the document. These elements shall not contain
requirements or any information considered indispensable for the use
of the document."
Unless otherwise specified, the execution of any subsequent evaluation
shall be abandoned if the current evaluation throws an exception or it
is the call to a noreturn function. Without this general implicit rule
the exception handling and noreturn functions would become almost
useless. The call to the deallocation function in a delete-expression
is a usual subsequent evaluation (I don't see any opposite statement
in C++03 or N3092).
VC++ 9.0 and Intel C++ 11.0.061 do not call the deallocation function
from a delete-expression if the object's destructor throws an
exception or calls std::exit or std::abort. If such a behavior is not
intended by the committee, this cannot be considered a compiler's bug
since there is no appropriate normative wording.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]