Re: [boost] [review] Review of Outcome (starts Fri-19-May)

Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)
From: Pete Bartlett (pete_at_[hidden])
Date: 2017-05-19 18:06:19

> Obviously the games
> and finance industries take a pretty consistent and strong opinion there
> i.e. globally disable all C++ exceptions,

FWIW this statement is too strong. The amount of C++ in the finance industry is vast , too vast for there to be an consistent no-exceptions theme. Indeed in my little corner it's the other world around - the bulk of code is compiled with exceptions /en/abled.

On 19 May 2017, at 00:04, Niall Douglas via Boost <boost_at_[hidden]> wrote:

>>> Once you've been using these things in your own code for a bit, for
>>> especially low level systems libraries you'd never willingly go back.
>>> The difference is very similar (to me at least) to that feeling you have
>>> when you must go back to writing C++ 98 without Boost after you've been
>>> using C++ 14 for a quite a while.
>> 
>> I trust your judgement on this. I just wish short examples in the docs
>> could convince me about that.
> 
> I did have some examples culled from real world usage in an earlier
> edition of the tutorial. People found them too hard to grok. They wanted
> toy, unrealistic examples instead, which is what you have now.
> 
>>> All that said, 60-70% of C++ would see no benefit to using Outcome nor
>>> Expected. Such code is always better off using only C++ exceptions.
>>> 
>> 
>> That leaves 30-40%, which is a huge market share.
> 
> If you follow the C++ Reddit on the topic of Either and Maybe monads, in
> the very long threads of bikeshedding you'll find one fairly widely held
> opinion that choosing something like Outcome is effectively the same as
> a library implementation of pre-table EH whereby a fixed overhead is
> added to all code execution in exchange for various benefits such as
> very fast handling of failure. Some would also argue that by forcing the
> programmer to manually write out the logic for handling failure at the
> point of failure, it improves auditing and maintenance of failure
> handling. This sort of C++ code, mostly low level systems programming,
> benefits from using something like Outcome.
> 
> However a majority of C++ very rarely needs to handle more than one form
> of failure in any given local use context. For this sort of C++,
> exceptions prevent cluttering the code with failure handling, and remove
> that fixed overhead from execution. They're a better choice, a better fit.
> 
> There are secondary arguments about cost of debugging and bringing code
> to production quality, but those are hard to prove. Obviously the games
> and finance industries take a pretty consistent and strong opinion there
> i.e. globally disable all C++ exceptions, but other users very
> interested in low latency do make use of C++ exceptions, so if you have
> talented programmers anything is possible, even easy. I suspect that in
> games and finance that assuming top notch programmers everywhere in a
> large org is unwise, so better avoid ruinous surprise by someone messing
> with code they don't understand.
> 
> Niall
> 
> -- 
> ned Productions Limited Consulting
> http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost