[scope] Some random thoughts
Hi All, Two observations from reading the docs. Why do I need a condition in scope_exit when I have a scope_fail? 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 } Regards, &rzej;
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. Internally, both scope_success and scope_fail are implemented on top of scope_exit and leverage its support for custom condition functions.
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.
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
On 12/3/23 01:31, Andrzej Krzemienski wrote:
sob., 2 gru 2023 o 22:20 Andrey Semashev via Boost <boost@lists.boost.org <mailto: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... <https://lastique.github.io/scope/libs/scope/doc/html/scope/scope_guards.html#scope.scope_guards.condition_functions>
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?
I do not have a real life use case but I also don't think that every condition must fall in the success/failure category. For example, you could log the state of your program in certain conditions, which are not necessarily a failure. class processor { private: std::queue<request> m_requests; bool m_interrupt; public: void enqueue_request(request const& req); void process_requests() { scope_exit logging_guard { [this] { // Log the state whether or not we're leaving // with an exception std::cout << m_requests.size() << " unprocessed requests left" << std::endl; }, [this] { return !m_requests.empty(); } }; while (!m_interrupt && !m_requests.empty()) { BOOST_SCOPE_FINAL [this] { m_requests.pop(); }; m_requests.front().process(); // may throw } } }; It is true that sometimes this can be achieved by using set_active() or even merging the condition into the action, but there may be cases when that is not convenient. Calling set_active needs to be done manually at every return point, which is error-prone. Merging the condition into action may be messy, especially if the condition is not so trivial and needs to be used in multiple scope guards. You can move the condition into a separate function object and reuse it with different actions. In any case, the support for condition function objects is needed by the library anyway, it's not like that functionality is unused. I don't see the reason to actively hide it from users.
On 1/10/24 18:52, Vinnie Falco wrote:
On Sat, Dec 2, 2023 at 5:38 PM Andrey Semashev via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
...
Whatever happened to this review?
We're still waiting for the review decision from Dmitry. There were holidays, so I'm being patient.
participants (3)
-
Andrey Semashev -
Andrzej Krzemienski -
Vinnie Falco