Proposed resolution:

Change [exception] to:

-1- The class exception defines the base class for the types of objects thrown as exceptions by C++ standard library components, and certain expressions, to report errors detected during program execution.

Each standard library class T that derives from class exception shall have a publicly accessible copy constructor and a publicly accessible copy assignment operator that do not exit with an exception. These member functions shall preserve the following postcondition: If two objects lhs and rhs both have dynamic type T, and lhs is a copy of rhs, then strcmp(lhs.what(), rhs.what()) == 0.

...

exception(const exception& rhs) throw();
exception& operator=(const exception& rhs) throw();

-4- Effects: Copies an exception object.

-5- Remarks: The effects of calling what() after assignment are implementation-defined.

-5- Postcondition: If *this and rhs both have dynamic type exception then strcmp(what(), rhs.what()) == 0.

[ 2009-10 Santa Cruz: ]

Moved to Ready after inserting "publicly accessible" in two places.

[ 2009-09-24 Niels provided updated wording: ]

I think the resolution should at least guarantee that the result of what() is independent of whether the compiler does copy-elision. And for any class derived from std::excepion that has a constructor that allows specifying a what_arg, it should make sure that the text of a user-provided what_arg is preserved, when the object is copied. Note that all the implementations I've tested already appear to satisfy the proposed resolution, including MSVC 2008 SP1, Apache stdcxx-4.2.1, GCC 4.1.2, GCC 4.3.2, and CodeGear C++ 6.13.

The proposed resolution was updated with help from Daniel Krügler; the update aims to clarify that the proposed postcondition only applies to homogeneous copying.

[ 2009-07-30 Niels adds: ]

Further discussion in the thread starting with c++std-lib-24512.

[ Batavia (2009-05): ]

Howard supplied the following replacement wording for paragraph 7 of the proposed resolution:

-7- Postcondition: what() shall return the same NTBS as would be obtained by using static_cast to cast the rhs to the same types as the lhs and then calling what() on that possibly sliced object.

Pete asks what "the same NTBS" means.

[ Sophia Antipolis: ]

The issue was pulled from Ready. It needs to make clear that only homogenous copying is intended to be supported, not coping from a derived to a base.

[ Bellevue: ]

Eric concerned this is unimplementable, due to nothrow guarantees. Suggested implementation would involve reference counting.

Is the implied reference counting subtle enough to call out a note on implementation? Probably not.

If reference counting required, could we tighten specification further to require same pointer value? Probably an overspecification, especially if exception classes defer evalutation of final string to calls to what().

Remember issue moved open and not resolved at Batavia, but cannot remember who objected to canvas a disenting opinion - please speak up if you disagree while reading these minutes!

Move to Ready as we are accepting words unmodified.

[ Batavia: Howard provided wording. ]

[ Redmond: Yes, this is fuzzy. The issue of derived classes is fuzzy too. ]

[lib.exception] specifies the following:

    exception (const exception&) throw();
    exception& operator= (const exception&) throw();

    -4- Effects: Copies an exception object.
    -5- Notes: The effects of calling what() after assignment
        are implementation-defined.

First, does the Note only apply to the assignment operator? If so, what are the effects of calling what() on a copy of an object? Is the returned pointer supposed to point to an identical copy of the NTBS returned by what() called on the original object or not?

Second, is this Note intended to extend to all the derived classes in section 19? I.e., does the standard provide any guarantee for the effects of what() called on a copy of any of the derived class described in section 19?

Finally, if the answer to the first question is no, I believe it constitutes a defect since throwing an exception object typically implies invoking the copy ctor on the object. If the answer is yes, then I believe the standard ought to be clarified to spell out exactly what the effects are on the copy (i.e., after the copy ctor was called).