sob., 2 gru 2023 o 22:20 Andrey Semashev via Boost <boost@lists.boost.org> napisał(a):
On 12/2/23 23:12, Andrzej Krzemienski via Boost wrote:
Hi All, Two observations from reading the docs.
Why do I need a condition in scope_exit when I have a scope_fail?
There is a discussion about this in this section:
https://lastique.github.io/scope/libs/scope/doc/html/scope/scope_guards.html...
In short, scope_fail implies processing a failure event (for whatever definition of "failure") and scope_exit has no such connotation and can be used with arbitrary conditions. The different scope guards have different default conditions, too.
Having read the linked section as well as your reply, I still do not understand the need for a scope_exit with a failure condition. I either want to *always* call the callback function on scope exit, or only under some condition. If it is under some condition, I would call scope_failure or scope_success respectively. Or are you saying that sometimes I want to call or skip the call based on random conditions not having to do with failing anything, and where the set_active would not work? Is that it? Do you have any convincing examples for this?
Internally, both scope_success and scope_fail are implemented on top of scope_exit and leverage its support for custom condition functions.
Ok, I get this part. I am just not sure if this is a sound design: because I reused a pattern in the implementation, I will expose it to the users. Regards, &rzej;
I recommend putting warning somewhere in the docs that while using scope guards you may inadvertently read an object after move:
std::string checked(std::string name) { scope::scope_exit g{[&]{ std::clog << "checked " << name <<std::endl; }};
validate(name); return name; // name becomes moved-from }
Interesting observation, thanks.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost