So why do developers continue to perpetuate the idea that the use of exceptions impacts performance or deterministic timing of code? It does not. It is no slower and no less deterministic than checking a return code or discriminated union. In fact that is exactly what implementations boil down to in compiled code, with the added benefit of being able to signal the failure to create an object in a way that makes it impossible to use the failed object accidentally. As I say, being able to return partial success is useful. Seeking to remove exceptions on performance grounds is a nonsense. On 13 Jun 2017 23:28, "Emil Dotchevski via Boost" <boost@lists.boost.org> wrote: On Tue, Jun 13, 2017 at 12:25 PM, Richard Hodges via Boost < boost@lists.boost.org> wrote:
Does anyone actually have a measurable example of real code in which the unexceptional path induces any more execution overhead than an optional/variant/outcome return type?
Because when I look at the code generated by gcc et all, I am convinced that you're solving a non-existant problem when seeking to replace exceptions.
By all means have a partial return type such as outcome if a failure is to result in a useful execution path.
But exceptions do not actually add overhead when used to signal actual exceptions.
At least in the millions of lines of code I have written and read.
All true. Noexcept is not better than using exception handling, it is better than *not* using exception handling without it. :) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost