|
Boost : |
Subject: Re: [boost] Boost.Outcome review - First questions
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2017-05-23 19:26:27
Le 23/05/2017 à 18:52, Emil Dotchevski via Boost a écrit :
> On Tue, May 23, 2017 at 7:37 AM, Niall Douglas via Boost <
> boost_at_[hidden]> wrote:
>
>> You could wholly replace all usage of C++ exceptions with Outcome
>> without losing fidelity of error information.
>>
>> (I wouldn't advise that you should, but you can)
>>
>> You would thus exchange (slightly) worse performance of successful code
>> in exchange for vastly better and predictable performance of
>> unsuccessful code.
>
> I keep seeing the assertion that C++ exceptions create performance problems
> but I am yet to see actual data to support it. Not a simple toy case but an
> actual program that was shown to be slow when using exceptions, that issue
> couldn't be fixed otherwise and the solution was to not use exceptions.
>
> Practically speaking exception handling overhead occurs only at function
> entry and exit. It disappears in thin air (all of it) by simply inlining
> the function, which would be done in performance-critical parts of the code
> anyway (and MSVC, whose exception handling overhead is probably the worst,
> can inline functions even at link time.)
>
> So I must ask: what is the practical problem solved by not using exceptions
> in general and Outcome in particular? It seems to me this is driven by a
> design preference for one coding style over another, which is fine, but
> nobody seems to be having that discussion. The cost of not using exceptions
> is that we're throwing away the ability to enforce postconditions. What's
> the upside?
>
Emil, I see expected as an alternative to output return codes, not to
exceptions.
We have output return codes in Filesystem. I adopted them in
Boost.Chrono and Boost.Thread. I regret it. If I have had expected at
the time, I would had used expected.
We can restrict the expected interface to avoid exception in some cases.
This introduce other issues, as constructors can not return anything
they must be replaced by factories that return expected. This impose a
big change on the way we program in C++, but people that don't use
exception have already to do something like that. expected makes all
this error handling more uniform.
Again, expected in not incompatible with exceptions.
Vicente
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk