Title
Order of destruction of parameters and temporaries
Status
cd1
Section
8.7 [stmt.jump]
Submitter
James Kanze

Created on 2001-03-28.00:00:00 last changed 162 months ago

Messages

Date: 2008-06-15.00:00:00

[Voted into the WP at the June, 2008 meeting.]

Date: 2006-11-15.00:00:00

Proposed Resolution (November, 2006):

Change 8.7 [stmt.jump] paragraph 2 as follows:

On exit from a scope (however accomplished), destructors (11.4.7 [class.dtor]) are called for all constructed objects with automatic storage duration (6.7.5.4 [basic.stc.auto]) (named objects or temporaries) that are declared in that scope, in the reverse order of their declaration. variables with automatic storage duration (6.7.5.4 [basic.stc.auto]) that have been constructed in that scope are destroyed in the reverse order of their construction. [Note: For temporaries, see 6.7.7 [class.temporary]. —end note] Transfer out of a loop...
Date: 2001-04-15.00:00:00

Notes from 04/01 meeting:

Any resolution of this issue should be careful not to introduce requirements that are redundant or in conflict with those of other parts of the IS. This is especially true in light of the pending issues with respect to the destruction of temporaries (see issues 86, 124, 199, and 201). If possible, the wording of a resolution should simply reference the relevant sections.

It was also noted that the temporary for a return value is also destroyed "out of order."

Note that issue 378 picks a nit with the wording of this same paragraph.

Date: 2008-07-27.00:00:00

According to 8.7 [stmt.jump] paragraph 2,

On exit from a scope (however accomplished), destructors (11.4.7 [class.dtor]) are called for all constructed objects with automatic storage duration (6.7.5.4 [basic.stc.auto]) (named objects or temporaries) that are declared in that scope, in the reverse order of their declaration.

This wording is problematic for temporaries and for parameters. First, temporaries are not "declared," so this requirement does not apply to them, in spite of the assertion in the quoted text that it does.

Second, although the parameters of a function are declared in the called function, they are constructed and destroyed in the calling context, and the order of evaluation of the arguments is unspecified (cf 7.6.1.3 [expr.call] paragraphs 4 and 8). The order of destruction of the parameters might, therefore, be different from the reverse order of their declaration.

History
Date User Action Args
2008-10-05 00:00:00adminsetstatus: dr -> cd1
2008-07-27 00:00:00adminsetmessages: + msg1743
2008-06-29 00:00:00adminsetstatus: ready -> dr
2008-03-17 00:00:00adminsetstatus: review -> ready
2008-02-03 00:00:00adminsetmessages: + msg1577
2008-02-03 00:00:00adminsetstatus: drafting -> review
2003-04-25 00:00:00adminsetstatus: open -> drafting
2001-05-20 00:00:00adminsetmessages: + msg503
2001-03-28 00:00:00admincreate