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.