Boost logo

Boost :

Subject: Re: [boost] Outcome v2
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-07-17 06:30:23

2017-07-15 23:23 GMT+02:00 Groke, Paul via Boost <boost_at_[hidden]>:

> > From: Emil DotchevskiSent: Freitag, 14. Juli 2017 18:37
> > To: boost_at_[hidden]
> >
> > 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).
> The question is: how do you interact with a return value of unknown type?
> For exceptions it's much easier. There is at least the common practice to
> derive your exception from std::exception, so if nothing else, you can at
> least get an error message. And you can catch base classes, which can also
> come in quite handy.

I think this can be done through Boost.TypeErasure. You can type erased
almost anything (almost like Boost.Any), subject to constraint that it has
to have member function `what()`. Then, you can query the erased object for
the type you are interested in handling.


Boost list run by bdawes at, gregod at, cpdaniel at, john at