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 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). Why wouldn't I just use a scope_final for those? . On Wed, Mar 22, 2023 at 9:41 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
Hi,
I'm proposing a Boost.Scope library for review and potential inclusion into Boost.
Boost.Scope is a small library implementing utilities defined in
from C++ Extensions for Library Fundamentals v3 with a few extensions. Namely, the library contains: * A number of scope guards for various use cases. * A unique resource wrapper that automatically frees the resource on destruction. * Utilities for wrapping POSIX-like file descriptors in the unique resource wrapper.
Compared to
, some notable extensions are: * A new scope_final scope guard, which is a more lightweight alternative to scope_exit. It is accompanied with the BOOST_SCOPE_FINAL macro that allows to simplify scope guard declaration syntax. * Scope guards can be activated/deactivated multiple times. * Scope guards can be created inactive initially. * Scope guard factory functions, for compatibility with C++11. * Support for optional resource traits in unique_resource wrapper, which improves usage with resources having unallocated values. * unique_resource supports swapping. * unique_resource supports dereferencing for any resource types that support dereferencing, not only pointers. * More flexible constructors for unique_resource.
The library requires C++11 at the minimum and will significantly benefit from C++17.
Source:
https://github.com/Lastique/scope
Docs:
https://lastique.github.io/scope/libs/scope/doc/html/index.html
Current state: Feature complete, tested in the CI.
I'm asking for a review manager and endorsements.
I'm also looking forward for any pre-review comments. In particular, I'm interested in community opinion on the following:
* Is there interest in this library at all? * Should it be merged with Boost.ScopeExit, which is currently unmaintained? More on this below. * Should some/all of the library components be lifted to namespace boost? Such is the practice with most vocabulary types in Boost, e.g. boost::atomic, boost::shared_ptr, boost::any, boost::string_view, etc. Currently, the library defines its names in namespace boost::scope. * Comments on the resource traits feature are especially welcome.
Re. Boost.ScopeExit. There is significant functionality overlap with it in the scope guards department. The docs contain comparison with it. I believe there is room for both libraries because Boost.ScopeExit supports C++03 and Boost.Scope provides better syntax and more features, and both can be useful in their own regards, although I expect Boost.Scope to be more appealing in newer code bases. However, if the community decides there's too much overlap, I'm not opposed to merging the two libraries, although Boost.ScopeExit currently depends on Boost.Function, Boost.Preprocessor and Boost.TypeOf, which are unnecessary for Boost.Scope.
Thank you.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost