On 9/27/23 19:13, Christian Mazakas via Boost wrote:

I'll endorse this library for inclusion into Boost.

It's small so it'll be easy to package for managers like vcpkg and Conan.

It solves a problem common to almost all C++ development.

I believe these two reasons alone are compelling enough to endorse this library.

However, I don't have the bandwidth to manage the review so that'll have to fall to someone else.

Thank you for the endorsement.

On 9/27/23 19:59, Alan de Freitas via Boost wrote:

Hi Andrey,

Thanks for the reminder about Boost.Scope. I endorse the library.

Thank you.

Em qui., 21 de set. de 2023 às 11:03, Andrey Semashev via Boost < boost@lists.boost.org> escreveu:

...

Hi,

This is a reminder that Boost.Scope is looking for endorsements and a review manager. Following is an excerpt from the previous announcement, describing the library.

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

The library is tested in CI and used in production in one of my projects.

Thanks.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

On 10/4/23 21:00, Дмитрий Архипов via Boost wrote:

I endorse the library and propose myself as the review manager.

Thank you for the endorsement and the offer to be the review manager. I'm happy to accept the offer.

чт, 21 сент. 2023 г. в 17:03, Andrey Semashev via Boost :

...

Hi,

This is a reminder that Boost.Scope is looking for endorsements and a review manager. Following is an excerpt from the previous announcement, describing the library.

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

The library is tested in CI and used in production in one of my projects.

Thanks.

On 10/9/23 18:33, Peter Dimov via Boost wrote:

Andrey Semashev wrote:

...

Source:

https://github.com/Lastique/scope

Docs:

https://lastique.github.io/scope/libs/scope/doc/html/index.html

Question:

What is the difference between scope_check, scope_success and scope_fail? Why do we need the second template parameter of the latter two if scope_check is provided?

Wouldn't it be clearer if scope_success and scope_fail took a single F parameter?

The second template parameter is the failure condition checker. It exists to allow for checking for different kinds of failure, other than whether there is an exception in flight. I wanted to support checking for error_codes and similar as an alternative to exceptions. For scope_success and scope_fail that template parameter is optional. The class templates exist because they were defined in the Fundamentals TS (although there the second template parameter is not present and the scope guards always unconditionally check for exceptions). scope_check is a generalization of scope_success and scope_fail. It does not assume exceptions and requires the user to provide his failure condition predicate. Other than that, it's functionally equivalent to scope_fail. If I was designing the library with no relation to the TS, I would probably only provide scope_check. I think, there is still a small value in having scope_success and scope_fail, since they make the common use case with exceptions a bit more concise. But the main reason for their existence is that I want to provide the scope guard names that are defined in the TS.

Also, wouldn't it be better if scope_exit took a second parameter C defaulting to "always" instead of having scope_check?

Do you mean to effectively rename scope_check to scope_exit, and add a default predicate that always returns true? I suppose, it is possible, although currently scope_exit is a bit more lightweight than scope_check. The latter is more complicated because the implementation should be prepared for the failure condition predicate constructor to throw. Perhaps, that is a good idea, if that extra overhead is not considered as a problem.

On 10/9/23 19:35, Peter Dimov via Boost wrote:

Andrey Semashev wrote:

...

On 10/9/23 18:33, Peter Dimov via Boost wrote:

...

Andrey Semashev wrote:

...

Source:

https://github.com/Lastique/scope

Docs:

https://lastique.github.io/scope/libs/scope/doc/html/index.html

Question:

What is the difference between scope_check, scope_success and scope_fail? Why do we need the second template parameter of the latter two if scope_check is provided?

Wouldn't it be clearer if scope_success and scope_fail took a single F parameter?

The second template parameter is the failure condition checker. It exists to allow for checking for different kinds of failure, other than whether there is an exception in flight. I wanted to support checking for error_codes and similar as an alternative to exceptions.

For scope_success and scope_fail that template parameter is optional. The class templates exist because they were defined in the Fundamentals TS (although there the second template parameter is not present and the scope guards always unconditionally check for exceptions).

scope_check is a generalization of scope_success and scope_fail. It does not assume exceptions and requires the user to provide his failure condition predicate. Other than that, it's functionally equivalent to scope_fail. If I was designing the library with no relation to the TS, I would probably only provide scope_check.

I think, there is still a small value in having scope_success and scope_fail, since they make the common use case with exceptions a bit more concise. But the main reason for their existence is that I want to provide the scope guard names that are defined in the TS.

I don't think this answers my question. I agree that scope_success<F> and scope_fail<F> need to be provided. I'm asking why we need scope_success and scope_fail, because it seems to me that one of these is exactly equivalent to scope_check and the other is the same with the condition reversed.

Mostly for completeness (i.e. to support arbitrary failure conditions in all checking scope guards) and because it doesn't cost anything. I don't see the value in restricting scope_success and scope_fail to just exceptions. In other words, if I compare the current implementation with two template parameters and a potential implementation with one, the former is more flexible, but other than that I see no difference. With all other things being equal, more flexible = more better.

Andrey Semashev wrote: ...

...

...

...

Source:

https://github.com/Lastique/scope

Docs:

https://lastique.github.io/scope/libs/scope/doc/html/index.html ... I have now merged scope_check into scope_exit, as you suggested. There is already a lightweight scope_final guard, so making scope_exit more feature-rich seemed like a good idea. Thanks for the suggestion.

In principle, the implementation can specialize scope_exit for the default case of always_true, so it doesn't have to be any less efficient than before.

Also, for anyone interested, I have created a single-header version of the library that is compatible with godbolt.org:

https://godbolt.org/z/6rvhnTrvn

Feel free to try it online.

PS: The single-header version is not part of the library, as proposed for inclusion into Boost. It's just to simplify the review process.

The review for Scope has been scheduled to take place November 26, 2023 - December 5, 2023 with me as the review manager. This will be a week after the next release (1.84). Hopefully everyone will have time to get some rest and join the review. вс, 15 окт. 2023 г. в 22:30, Andrey Semashev via Boost :

On October 15, 2023 8:17:10 PM Peter Dimov via Boost wrote:

...

Andrey Semashev wrote: ...

...

...

...

...

Source:

https://github.com/Lastique/scope

Docs:

https://lastique.github.io/scope/libs/scope/doc/html/index.html ... I have now merged scope_check into scope_exit, as you suggested. There is already a lightweight scope_final guard, so making scope_exit more feature-rich seemed like a good idea. Thanks for the suggestion.

In principle, the implementation can specialize scope_exit for the default case of always_true, so it doesn't have to be any less efficient than before.

Yes, I thought so too. I even had the idea of making void the default and specialize for that. But the current implementation should be efficient as well, although it requires more template machinery to eliminate the runtime overhead. It might affect compile times though.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost