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
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