On 4/17/23 00:57, Edward Catmur wrote:
>
>
> On Sun, 16 Apr 2023 at 18:29, Andrey Semashev via Std-Discussion
> <std-discussion_at_[hidden]
> <mailto:std-discussion_at_[hidden]>> wrote:
>
> On 4/16/23 22:30, Edward Catmur wrote:
> >
> > On Sun, 16 Apr 2023, 15:36 Andrey Semashev via Std-Discussion,
> > <std-discussion_at_[hidden]
> <mailto:std-discussion_at_[hidden]>
> > <mailto:std-discussion_at_[hidden]
> <mailto:std-discussion_at_[hidden]>>> wrote:
> >
> > No, scope guards *are* moveable. And I can imagine use cases
> that rely
> > on them being moveable, like returning an epilogue from a
> function.
> >
> > auto start_transaction(transaction_data& tr)
> > {
> > scope_exit completion_guard([&] { tr.complete(); });
> > tr.init_with_data_data(x, y, z);
> > return completion_guard;
> > }
> >
> > And regarding storage, here's another use case that makes use
> of a scope
> > guard as a non-automatic object - program exit handlers.
> >
> > // At namespace scope
> > scope_exit at_exit_guard([] { puts("Good bye cruel world!"); });
> >
> > Or make that thread_local to make it a thread exit handler.
> >
> > Those are both scope_exit, though, not scope_success or scope_failure.
> > When would it make sense to return one of the latter two or to use
> them
> > at namespace scope?
>
> If you define it so that scope_fail is called when main() or a thread
> entry function is left with an exception, it could be used for the final
> cleanup before program termination. For example, collect a backtrace
> before terminating or emit a critical message in the log.
>
> I think uncaught_exceptions() can only be 0 or 1 at that point, though,
> so you may as well test it directly and not have to worry about the
> cached value being nonzero?

Yes, you could. But scope_fail does that for you, so why would you?