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_...(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
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/...
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.