
9 Apr
2023
9 Apr
'23
12:20 a.m.
niedz., 9 kwi 2023 o 02:16 Andrzej Krzemienskinapisał(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 >> >