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

2024-11-11

887. Move construction of thrown object

[Voted into WP at March, 2010 meeting.]

11.4.5.3 [class.copy.ctor] paragraph 16 details the conditions under which a thrown object can be moved instead of copied. However, the optimization as currently described is unsafe. Consider the following example:

    void f() {
        X x;
        try {
            throw x;
        } catch (...) {
        }
        // x may have been moved from but can still be accessed here
    }

When the operation is a throw, as opposed to a return, there must be a restriction that the object potentially being moved be defined within the innermost enclosing try block.

Notes from the July, 2009 meeting:

It is not clear how important this optimization is in the context of throw: how often is a large object with substantial copying overhead thrown? Also, throwing an exception is already a heavyweight operation, so presumably moving instead of copying an object would not make much difference.

Proposed resolution (October, 2009):

Change 11.4.5.3 [class.copy.ctor] paragraph 17 second bullet as follows:

• in a throw-expression, when the operand is the name of a non-volatile automatic object whose scope does not extend beyond the end of the innermost enclosing try-block (if there is one), the copy operation from the operand to the exception object (14.2 [except.throw]) can be omitted by constructing the automatic object directly into the exception object