Re: [scope] Proposing Boost.Scope

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2023-03-22 09:03:56

On 3/22/23 05:02, Klemens Morgenstern wrote:
> I've written my own replacement and am very much in favor of the
> scope-utilities.
> 
> Have you thought about if this can be made to work with
> system::error_code or even system::result? E.g.
> 
> make_scope_fail <https://lastique.github.io/scope/libs/scope/doc/html/boost/scope/make_scope_fail.html>(ec, handle) // checks ec in order to decide if it failed

I haven't thought about this, but it sounds like an interesting
potential extension. In general, it might be useful to be able to
specify a failure detection function, which by default would be to check
for an exception, but could be changed to check an error_code or some
arbitrary result code (e.g. from errno).

This could look like this:

  error_code ec;
  scope_fail guard(
    [&] { std::cout << "Failure" << std::endl; },
    [&ec] { return !!ec; });

Similarly with make_scope_fail. There is a small complication with the
active flag that can be specified as the second argument currently, but
I think I could make it mandatory in this case, or do some type
deduction heuristic. I'll need to think about this.

> The unique_resource seems very specific for file descriptors to me,
> because almost everything else can be put into a unique_ptr (e.g. FILE
> or HANDLE).

unique_ptr is only useful for pointers, and indeed pointers are more
prevalent for as resource handles. unique_resource would fill the gap
for non-pointer resources. And BTW, although HANDLE is a pointer
internally, the type itself is not spelled as a pointer, so you can't
write `unique_ptr<HANDLE, deleter>`. You'd have to use remove_pointer on
it. I would be more comfortable to use unique_resource in this case.

>From personal experience, I have seen some libraries which exposed their
objects as non-pointer handles (typically structures) that needed to be
freed. For example:

https://github.com/xiph/speex/blob/f39602dadbb6d0e8fa7b548c1629388290d4a0f7/include/speex/speex_bits.h#L49-L59

> Why wouldn't I just use a scope_final for those?

Although you can create scope guards as class members, this is not their
primary intended use case. You have no access to the stored function
object, and consequently, any data it binds, which means the resource
itself will need to be stored externally, which is a hassle.
Furthermore, this would complicate move operations of your class because
you would have to ensure that the scope guard always references the
correct external resource object. Just imagine if you had to replace
every unique_ptr with a scope guard in your classes.