niedz., 9 kwi 2023 o 02:16 Andrzej Krzemienski 
napisał(a):

>
>
> niedz., 9 kwi 2023 o 00:28 Andrey Semashev via Boost <
> boost@lists.boost.org> napisał(a):
>
>> On 4/7/23 18:42, Andrey Semashev wrote:
>> > On 4/7/23 15:55, Andrzej Krzemienski wrote:
>> >> czw., 6 kwi 2023 o 23:51 Andrey Semashev via Boost
>> >> > napisał(a):
>> >>
>> >>     Thus I
>> >>     wouldn't say scope_success/scope_fail are unimplementable - they
>> clearly
>> >>     are - but that they are incompatible with coroutines. That is,
>> these
>> >>     scope guards will work as expected as long as you don't switch
>> >>     coroutines within the guarded scope.
>> >>
>> >> Maybe this is just a question of the choice of words.
>> >> But the docs do not present the situation in this way.
>> >>
>> >> "Although it is possible to specify arbitrary condition function
>> >> objects, typically |scope_success
>> >> <
>> https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_success.html>|
>> invokes its action when the scope is left normally (i.e. not via an
>> exception) and |scope_fail <
>> https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail.html>|
>> should typically be used to handle errors, including exceptions."
>> >>
>> >> This guarantee (when scope is exited not normally) cannot be satisfied
>> >> in general. One cannot use it in a coroutine: directly or indirectly.
>> >> One might not even know the context.
>> >>
>> >> "By default, |scope_success
>> >> <
>> https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_success.html>|
>> will invoke its action if it is destroyed normally, |scope_fail <
>> https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail.html>|
>> - if it is destroyed due to an exception being thrown."
>> >
>> > Note the "typically". :) In this documentation I tried to describe these
>> > facilities in more or less simple language, describing the most typical
>> > use cases. For this simplicity, I had to omit some formalities and
>> > corner cases that would detract the reader from the main purpose and
>> > intended use case of the components. Perhaps, I should improve the
>> > wording, but I would still like the docs to be easily readable.
>> >
>> > And, as I admitted earlier, I completely forgot about coroutines. I will
>> > add a note about coroutenes in relation to the default failure condition
>> > used by scope_success/scope_fail.
>> >
>> >> (BTW, The synopsis in
>> >>
>> https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail.html
>> <
>> https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/scope_fail.html
>> >
>> >> does not indicate that there is any default Cond.)
>> >
>> > Hmm, for some reason Doxygen removed the default template arguments for
>> > scope_success/scope_fail. I'll see if I can fix this. Thanks for
>> noticing.
>>
>> I have updated the docs to fix those issues and added the note re.
>> coroutines. I've also improved wording so that the general discussion
>> does not focus on exceptions as much but rather failure and non-failure
>> conditions.
>>
>
> Thanks.
>
> 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


> Regarding failure conditions other than exceptions, the problem with
> coroutines may still appear if a thread-local storage is used, such as
> errno.
>
> Regards,
> &rzej;
>
>
>>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
>