Re: [scope] Scope review starts on November 26th

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2023-11-26 12:47:02

On 11/26/23 05:41, Peter Dimov via Boost wrote:
> Andrey Semashev wrote:
>> Specifically regarding Boost.Scope, the extensions I made are what makes
>> these components practically useful in my real code base. That is, I
>> find the standard components too limiting or inconvenient to be useful
>> in practice.
> 
> Can you please go into more detail on that? Maybe give a specific examples
> for the use cases in which the standard-proposed components don't work
> well but Boost.Scope does.

Majority of my scope guard uses are BOOST_SCOPE_FINAL. This means that
most of the time I don't need the ability to cancel the scope guard and
don't want to invent its name (especially when there are multiple scope
guards in a function).

I have a few cases where I need to create an inactive scope guard and
activate it later - typically, based on some condition deeper within the
function. I also have a case where I need to create a scope guard that
is conditionally active, and whether it is active is decided elsewhere
(e.g. passed into the function as a parameter).

Although I currently don't use unique_resource, I was using it at some
point and found resource traits to be useful - specifically, with POSIX
file descriptors. I find the need to use make_unique_resource_checked to
construct the unique resource a significant inconvenience and
error-prone practice. We don't need to use such a helper function
neither with smart pointers nor with optional<>, and it is easy to
forget that we need to use it with unique_resource. (In case if anyone
wonders, constructing `unique_resource(fd, &::close)` is likely
incorrect because it will always call `::close` on the fd on
destruction, even if it is invalid.) Also, the fact that
`std::unique_resource` would have double the size of an fd (due to the
added `bool`) bothers me.

A note on why I'm no longer using unique_resource. It's because I now
have a dedicated `posix_file` class that wraps an fd and also provides a
set of operations on files that I need (read, write, etc.). I still
think `unique_resource` is useful though, because using a
`unique_resource` (or `unique_fd` that is provided by Boost.Scope) has a
much lower cost than writing such a class. One would typically spend the
time on writing a special class like `posix_file` when there are lots of
places where he would need that extra functionality. When your
interaction with fds is episodic, it is easier to just use `unique_fd`
where needed.