Re: [boost] Outcome v2

On Fri, Jul 14, 2017 at 12:27 AM, Groke, Paul via Boost < boost@lists.boost.org> wrote:

...

From: Emil Dotchevski via Boost Sent: Donnerstag, 13. Juli 2017 20:12

...

Have you thought about using a type-erased factory - like function - as the error type?

exception_ptr needs a memory allocation so that's a no-go.

Yes, exception_ptr needs a memory allocation. And atomic ref counting. Which is why I wrote factory function. The idea is that most of the time, you don't want/need to inspect the error, you just have to know that it happened and maybe be able to pass it on. Which can be very efficient if you return a factory.

I understand that this is far from perfect, but it's the best idea I have for a single type that can transport arbitrary error information. (An alternative would be a functor that throws the exception when called, but AFAIK that will be even slower - much slower.)

Ah, now I get it, thanks for the explanation. There *might* even be a way to get this to work even without memory allocation in the end (without exception_ptr), but I think this is perhaps missing the point of returning an error object, which is to be able to interact with it. Also, reasonably if you could fit the things you need to create the object into a "small object optimized" buffer, you can probably fit the object itself into the same buffer. Noexcept already has that, it's the result<T> object, however it might be too heavy to return up the call chain one level at a time (it is instead designed for capturing the TLS-stored object to postpone its handling, perhaps after moving it to another thread).