STL icon indicating copy to clipboard operation
STL copied to clipboard

<exception>: Consider changing exception_ptr to have the size of a single pointer

Open jwtowner opened this issue 5 years ago • 3 comments

Hi!

I'm wondering if it's not too late to request an ABI breaking change to shrink the size of the STL's std::exception_ptr class type down to match that of a single pointer. Currently, it uses a std::shared_ptr to manage the lifetime of the stored exception object, and this naturally requires two pointer-sized variables for the std::shared_ptr's state. By changing the internal representation of std::exception_ptr over to an intrusive reference-counted pointer implementation, it would be possible to make sizeof(std::exception_ptr) == sizeof(void*).

The reason this would be valuable is it makes implementing both P1028 and P0709 much easier, in particular type-erasing a std::exception_ptr object and storing it in a std::system_code, which uses a single std::intptr_t for state. Both of these proposals, while well received, are still a long way off and may never land in their present form. However, there is an open source implementation and other libraries using the same technique (the company I work has its own implementation of P1028 used for exceptionless futures/promises and senders/receivers). With std::exception_ptr being larger than std::uintptr_t as it currently is in the Microsoft STL, the only way to do this type-erasure is to allocate additional memory, which would be nice to avoid inside of error handling code paths.

Both libc++ and libstdc++ appear to use the intrusive-reference counting approach for std::exception_ptr and have sizeof(std::exception_ptr) == sizeof(void*), so you would also be hitting parity with these libraries if the change were to be done.

vNext note: Resolving this issue will require breaking binary compatibility. We won't be able to accept pull requests for this issue until the vNext branch is available. See #169 for more information.

jwtowner avatar Apr 26 '20 21:04 jwtowner

Definitely not too late - we're still many months away from restarting work on vNext. Thanks for the suggestion and especially the rationale - I've relabeled this issue accordingly.

StephanTLavavej avatar Apr 27 '20 00:04 StephanTLavavej

@CaseyCarter says that this is a no-brainer and that we should do this for vNext.

StephanTLavavej avatar Apr 29 '20 20:04 StephanTLavavej

It seems intentionally allowed to define exception_ptr in another namespace (and with a possibly differerent name) and then drag it into std by using/typedef, which can sightly improve throughput since ADL would find fewer overloads of operator== etc.. Perhaps we can also do this in vNext.

frederick-vs-ja avatar Dec 29 '23 09:12 frederick-vs-ja