Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)

Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-01-28 13:37:31

> So the question is what's the upside of using the
> cumbersome macro rather than relying on exception handling? Is it just the
> perceived performance improvement?

Outcome's default configuration is to do nothing when E is a UDT. If E
matches the various documented traits, observing T when an E is present
will throw various exceptions according to the rules you tell it. The
TRY operation is therefore an alternative way of unwinding the stack
than throwing exceptions, one which does not invoke EH table scans.

Sure, it's more manual and cumbersome, but it also means that the
failure handling path has the same latency as the success handling path.
And yes, if your EH implementation in the compiler is not table based,
then there is not much performance gain.

Some on WG21 have mused about an attribute by which one could mark up a
function, class or namespace to say "please use balanced EH here". It
would not be an ABI break, and code with the different EH mechanisms
could intermix freely. If Outcome is successful in terms of low latency
userbase, I don't doubt that SG14 will propose just such an EH attribute
in the future.

Until then, this is a library based solution.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/