Movatterモバイル変換

This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 119a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2025-12-20

220. All deallocation functions should be required not to throw

[Voted into the WP at the September, 2008 meeting (resolutionin paper N2757).]

[Picked up by evolution group at October 2002 meeting.]

The default global operatorsdelete are specified to notthrow, but there is no requirement that replacement global, orclass-specific, operatorsdelete must not throw. That oughtto be required.

In particular:

• 6.8.6.5.3 [basic.stc.dynamic.deallocation] paragraph 2, at the end of thefirst sentence, should also require that no exceptions be thrown.
• 11.4.11 [class.free], including its examples, should requirenonthrowing class-specificoperator delete.
• 16.4.5.6 [replacement.functions] paragraph 2 should appendthrow() to the signature of each of the four operatorsdelete.

We already require that all versions of an allocator's deallocate()must not throw, so that part is okay.

Rationale (04/00):

1. Replacement deallocation functions are already required not tothrow an exception (cf 16.4.5.8 [res.on.functions] paragraph 2,as applied to 17.6.3.2 [new.delete.single] paragraph 12 and17.6.3.3 [new.delete.array] paragraph 11).
2. Section 16.4.5.6 [replacement.functions] is describing thesignatures of the functions to be replaced; exception specficationsare not part of the signature.
3. There does not appear to be any pressing need to require thatclass member deallocation functions not throw.

Note (March, 2008):

The Evolution Working Group has accepted the intent of this issueand referred it to CWG for action for C++0x (see paperJ16/07-0033 = WG21 N2173).

Proposed resolution (March, 2008):

Change 6.8.6.5.3 [basic.stc.dynamic.deallocation] paragraph 3 as follows:

A deallocation function shall not terminate by throwing anexception.The value of the first argument supplied to a deallocation function...