All deallocation functions should be required not to throw
Section [basic.stc.dynamic.deallocation]
Herb Sutter

Created on 2000-03-31.00:00:00 last changed 161 months ago


Date: 2002-10-15.00:00:00

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

Date: 2008-09-15.00:00:00

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

Date: 2008-03-15.00:00:00

Proposed resolution (March, 2008):

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

A deallocation function shall not terminate by throwing an exception. The value of the first argument supplied to a deallocation function...
Date: 2008-03-15.00:00:00

Note (March, 2008):

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

Date: 2000-04-15.00:00:00

Rationale (04/00):

  1. Replacement deallocation functions are already required not to throw an exception (cf [res.on.functions] paragraph 2, as applied to [new.delete.single] paragraph 12 and [new.delete.array] paragraph 11).
  2. Section [replacement.functions] is describing the signatures of the functions to be replaced; exception specfications are not part of the signature.
  3. There does not appear to be any pressing need to require that class member deallocation functions not throw.
Date: 2007-09-09.00:00:00

The default global operators delete are specified to not throw, but there is no requirement that replacement global, or class-specific, operators delete must not throw. That ought to be required.

In particular:

  • [basic.stc.dynamic.deallocation] paragraph 2, at the end of the first sentence, should also require that no exceptions be thrown.
  • 11.11 [class.free], including its examples, should require nonthrowing class-specific operator delete.
  • [replacement.functions] paragraph 2 should append throw() to the signature of each of the four operators delete.

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

Date User Action Args
2008-10-05 00:00:00adminsetmessages: + msg1805
2008-10-05 00:00:00adminsetstatus: review -> cd1
2008-05-18 00:00:00adminsetmessages: + msg1647
2008-05-18 00:00:00adminsetstatus: open -> review
2008-03-17 00:00:00adminsetmessages: + msg1619
2008-03-17 00:00:00adminsetstatus: extension -> open
2002-11-08 00:00:00adminsetmessages: + msg791
2002-11-08 00:00:00adminsetstatus: nad -> extension
2000-05-21 00:00:00adminsetmessages: + msg370
2000-03-31 00:00:00admincreate