Re: [scope] scope_fail is unimplementable

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2023-04-09 01:02:06

On 4/9/23 03:20, Andrzej Krzemienski wrote:
> 
>     Well, in my experience, the scope fail/success is exclusively about
>     exceptions, so I will still focus on exceptions.
>     Here is a small benchmark comparing the deactivation-based mechanism
>     of a scope_guard with uncaught_exception-based mechanism of scope_fail.
>     The former performed like 36 times faster, as it doesn't have to
>     perform the calls to the runtime.
> 
> Sorry. Forgot the link. Here it is:
> https://quick-bench.com/q/0InBohGrnD5-soYT_GwvaCEaG74
> <https://quick-bench.com/q/0InBohGrnD5-soYT_GwvaCEaG74>

The thing with manually dismissing (or activating) the scope guard
before leaving the scope diminishes the usefulness of the scope guard.
The first and foremost reason to use a scope guard is to automate
execution of the action upon exiting the scope. If you now have to
manually ensure this at every point where you might leave the function,
what's the point of using it in the first place?

Yes, you can manually (de)activate the guard in small and contained
cases, but in general I would very much prefer it to work automatically.
Otherwise, it quickly becomes a maintenance nightmare that it was
supposed to fix.

>     Regarding failure conditions other than exceptions, the problem with
>     coroutines may still appear if a thread-local storage is used, such
>     as errno.

errno is volatile (not in core C++ terms but in terms of it changing its
value in various non-obvious ways), so you would normally read its value
into a local variable immediately after a syscall for testing before
returning. It is that local variable that you check in the scope guard,
not errno itself.