[cpp-threads] Issue 1369 --- thread safety of std::rethrow_exception

[N.M. Maclaren]

On Nov 16 2010, Anthony Williams wrote:
>>>
>>> In order to clone exceptions you need two things: the size of the
>>> object to clone (so you can allocate space for the new one), and the
>>> ability to call the copy constructor so you can actually do the copy.
>>
>> You also need the constraint that all exceptions HAVE a copy constructor,
>> with the usual semantics. I don't see that in the existing standard.
>
>15.1p3 of the FCD says:
>
>"... Except for these restrictions and the restrictions
>on type matching mentioned in 15.3, the operand of throw is treated 
>exactly as a function argument in a
>call (5.2.2) or the operand of a return statement."

Right.  The former doesn't even require value semantics - e.g. Fortran
can pass functions that way.  The latter is a little murkier, but there
are lots of non-copyable objects that can be returned my moving them.

>and p5 says:
>
>"When the thrown object is a class object, the copy/move constructor and 
>the destructor shall be accessible,
>even if the copy/move operation is elided (12.8)."
>
>Hmm. In C++03, exceptions had to be copyable. It looks like in C++0x 
>they can be move-only. Was this deliberate?

That's the thrown object and NOT the exception object - the reason that
the thrown object has to be moveable is because it is copied/moved into
the exception object.  All of the handling of the actual exception object
is done entirely by the implementation (see paragraphs 3 and 4).

That's almost the only way in which it can be implemented, incidentally,
at least in implementations that provide any functionality above that
which is required by the C++ standard.


Regards,
Nick Maclaren.