Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk