Proposed resolution (February, 2013): Change 6.3 [basic.def.odr] paragraph 2 as follows: Change 7.6.2.8 [expr.new] paragraph 17 as follows: Change 11.4.7 [class.dtor] paragraph 11 as follows:
for a constructed object for a constructed object for a constructed object for a constructed temporary object
In each case, the context of the invocation is the context of
the construction of the object. A destructor is also invoked
implicitly through use of a delete-expression (7.6.2.9 [expr.delete]) for a constructed object allocated by a
new-expression (7.6.2.8 [expr.new]); the context of the
invocation is the delete-expression. [Note: An array of
class type contains several subobjects for each of which the
destructor is invoked. —end note] A destructor can also
be invoked explicitly. A destructor is potentially invoked if
it is invoked or as specified in 7.6.2.8 [expr.new] and
11.9.3 [class.base.init]. A program is ill-formed if Add the following as a new paragraph following
11.9.3 [class.base.init] paragraph 9: If a given non-static data member has both... In a non-delegating constructor, the destructor for each
direct or virtual base class and for each non-static data member of
class type is potentially invoked (11.4.7 [class.dtor]). [Note: This provision ensures that destructors
can be called for fully-constructed sub-objects in case an exception
is thrown (14.3 [except.ctor]). —end
note] In a non-delegating constructor, initialization proceeds...
...A destructor for a class is odr-used
as specified in
if it is potentially invoked (11.4.7 [class.dtor]).
If the new-expression creates an object or an array of objects
of class type, access and ambiguity control are done for the
allocation function, the deallocation function (11.4.11 [class.free]), and the constructor (11.4.5 [class.ctor]). If
the
new expression new-expression creates
an array of objects of class type, access and ambiguity control
are done for the destructor is potentially invoked
(11.4.7 [class.dtor]).
Destructors are A destructor is invoked implicitly
s with static
storage duration (6.8.6.2 [basic.stc.static]) at program termination
(6.10.3.3 [basic.start.dynamic]),s with thread
storage duration (6.8.6.3 [basic.stc.thread]) at thread exit,s with automatic
storage duration (6.8.6.4 [basic.stc.auto]) when the block in which
an object is created exits (8.10 [stmt.dcl]),s when
the its lifetime of a temporary
object ends (6.8.7 [class.temporary]),.
for constructed objects allocated by a new-expression
(7.6.2.8 [expr.new]), through use of a
delete-expression (7.6.2.9 [expr.delete]),in several situations due to the handling of exceptions
(14.4 [except.handle]).an
object of class type or array thereof is declared and the destructor
for the class is not accessible at the point of the declaration
a destructor that is potentially invoked is deleted or not
accessible from the context of the invocation. Destructors
can also be invoked explicitly.
The current specification does not appear to say whether an implementation
is permitted/required/forbidden to complain when a sub-object's destructor
is inaccessible. In particular, if there is no possibility for an
exception to be thrown following a given sub-object's construction,
should an implementation issue an error if that sub-object's destructor is
inaccessible?