Question

I’ve noticed a slight discrepency in how MSVC and g++ handle creation of the temporary exception object when the thrown type is movable. Hunting these down raised additional questions.

Before going any further, here is the core of my question: in the absense of copy/move elision, who well does the standard say how the temporary exception object should be created? At the moment, the best I’ve been able to do is the following quote, from 15.1/3:

A throw-expression initializes a temporary object, called the exception object, the type of which is determined by removing any top-level cv-qualifiers from the static type of the operand of throw and adjusting the type from “array of T” or “function returning T” to “pointer to T” or “pointer to function returning T”, respectively.

I’m guessing the answer is buried somewhere in language elsewhere that defines the type of an expression and how objects are initialized, but I’m having no luck piecing it all together. When an object is thrown, does the exception object get (a) copy constructed, (b) move constructed if appropriate, and copy constructed otherwise, or (c) initialized in an implementation defined manner?

Consider the following code:

#include <iostream>
using std::cout;
using std::cin;
using std::endl;

struct Blob {
  Blob() { cout << "C" << endl; }
  Blob(const Blob&) { cout << "c" << endl; }
  Blob(Blob&&) { cout << "m" << endl; }
  Blob& operator =(const Blob&) { cout << "=" << endl; return *this; }
  Blob& operator =(Blob&&) { cout << "=m" << endl; return *this; }
  ~Blob() { cout << "~" << endl; }

  int i;
};

int main() {
  try {
     cout << "Throw directly: " << endl;
     throw Blob();
  } catch(const Blob& e) { cout << "caught: " << &e << endl; }
  try {
     cout << "Throw with object about to die anyhow" << endl;
     Blob b;
     throw b;
  } catch(const Blob& e) { cout << "caught: " << &e << endl;  }
  {
    cout << "Throw with object not about to die anyhow (enter non-zero integer)" << endl;
    Blob b;
    int tmp;
    cin >> tmp; //Just trying to keep optimizers from removing dead code
    try {
      if(tmp) throw b;
      cout << "Test is worthless if you enter '0' silly" << endl;
    } catch(const Blob& e) { cout << "caught: " << &e << endl;  }
    b.i = tmp;
    cout << b.i << endl;
  }
}

This is all recreated on ideone. As you can [hopefully] see, gcc via ideone creates the Blob object in place in the first case, and moves in the second two. The results are summarized below, with the pointer values replaced with identifiers.

Throw directly: 
C {A}
caught: {A}
~ {A}
Throw with object about to die anyhow
C {A}
m {B} <- {A}
~ {A}
caught: {B}
~ {B}
Throw with object not about to die anyhow (enter non-zero integer)
C {A}
m {B} <- {A}
caught: {B}
~ {B}
2
~ {A}

The same code in MSVC2010, regardless of optimization settings, the results are the same except the two moves are copies. This is the difference that initially caught my eye.

The first test I assume is fine; its classic copy elision.

In the second test, gcc behaves the way I would have expected. The temporary Blob is treated as an xvalue, and the exception object is move constructed from it. But I’m not sure if the compiler is required to recognize that the original Blob is expiring; if it isn’t it, then MSVC is acting correctly when it copies. Thus my original question: does the standard mandate what happens here, or is it just part of the implementation defined behavior inherant to exception handling?

The third test is exactly the opposite: MSVC behaves the way my intuition demands. gcc choses to move from b, but b is still live, as evidenced by the fact that I continue to work with it after handling the thrown exception. Obviously, in this trivial example, moving or copying makes no difference to b itself, but surely the compiler isn’t allowed to look at that when considering overload resolution.

Obviously, the presence of copy/move elision makes this simple test hard to generalize from, but the bigger issue is that either compiler might not be complient just yet [particularly in gcc’s case with the third test, and MSVC in general].

Note this is entirely for academic purposes; I almost never throw anything except a temporary, which both compilers construct in place anyhow, and I’m quite certain that behavior is allowed.

Answer 1

The move behavior is conforming for case 2, but not case 3. See 12.8 [class.copy]/p31:

When certain criteria are met, an
implementation is allowed to omit the
copy/move construction of a class
object, even if the copy/move
constructor and/or destructor for the
object have side effects. …

…

• in a throw-expression, when the operand is the name of a non-volatile
  automatic object (other than a
  function or catch-clause parameter)
  whose scope does not extend beyond the
  end of the innermost enclosing
  try-block (if there is one), the
  copy/move operation from the operand
  to the exception object (15.1) can be
  omitted by constructing the automatic
  object directly into the exception
  object

The above doesn’t define when an object can be implicitly moved. But it does define when copy/move elision is legal. To get when implicit move is legal you have to go down to paragraph 32 in the same section:

32 When the criteria for elision of a
copy operation are met or would be met
save for the fact that the source
object is a function parameter, and
the object to be copied is designated
by an lvalue, overload resolution …

This paragraph explains that when copy/move elision is legal, then overload resolution happens with two passes:

1. First pretend the lvalue is an rvalue in deciding what constructor is going to be called or elided.

2. If 1) fails, then repeat overload resolution with the argument as an lvalue.

This has the effect of producing a hierarchy of move semantics from best to worst:

1. If you can elide construction, do so.
2. Else if you can move the object out, do so.
3. Else if you can copy the object out, do so.
4. Else emit a diagnostic.

Note that these are essentially the same rules for the ordinary return of local stack objects.