This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115f. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-12-06
[Moved to DR at the September, 2013 meeting.]
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?
Proposed resolution (February, 2013):
Change 6.3 [basic.def.odr] paragraph 2 as follows:
...A destructor for a class is odr-usedas specified inif it is potentially invoked (11.4.7 [class.dtor]).
Change 7.6.2.8 [expr.new] paragraph 17 as follows:
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 thenew expressionnew-expression creates an array of objects of class type,access and ambiguity control are done forthe destructor is potentially invoked (11.4.7 [class.dtor]).
Change 11.4.7 [class.dtor] paragraph 11 as follows:
Destructors areA destructor is invoked implicitly
for a constructed object
swith static storage duration (6.7.5.2 [basic.stc.static]) at program termination (6.9.3.3 [basic.start.dynamic]),for a constructed object
swith thread storage duration (6.7.5.3 [basic.stc.thread]) at thread exit,for a constructed object
swith automatic storage duration (6.7.5.4 [basic.stc.auto]) when the block in which an object is created exits (8.8 [stmt.dcl]),for a constructed temporary object
swhentheits lifetimeof a temporary objectends (6.7.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]).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
an object of class type or array thereof is declared and the destructor for the class is not accessible at the point of the declarationa destructor that is potentially invoked is deleted or not accessible from the context of the invocation.Destructors can also be invoked explicitly.
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...