Closed frederick-vs-ja closed 2 months ago
Is there any reason why we couldn't say that exception objects have dynamic storage duration? It seems like "temporary" is indeed wrong, as they're not destroyed at the end of the full-expression in which they're created. But giving them dynamic storage duration does not prevent having a rule saying that the implementation destroys them at a particular point which just happens to coincide with the point where the storage is released.
It looks like [except.throw] already has all the pieces we need: it says that first memory is allocated in an unspecified way, then there is an unspecified last point where the exception object is destroyed, and finally, "The implementation may then deallocate the memory for the exception object; any such deallocation is done in an unspecified way."
I think in [except.throw]/3 we can just replace "temporary object" with "object with dynamic storage duration".
CWG2854
It seems that we should also strike [class.temporary] p1.3 and the related note.
Good point. Fixed.
Full name of submitter (unless configured in github; will be published with the issue): Jiang An
Reference (section label): [basic.stc.general], [except.throw]
Link to reflector thread (if any):
Issue description:
The recently approved resolution of CWG2533 makes the storage durations of temporary objects fall into static, thread, and automatic storage durations, which should partially resolve CWG1634.
However, exception objects are also categorized as temporary objects ([except.throw] p3), and the duration of their storage doesn't actually follow the convention of static, thread, automatic, or dynamic storage duration. Perhaps exception objects deserve their own storage class.
Suggested resolution: