- Boost - lists.preview.boost.org

Reminder: Release Notes
by Marshall Clow 30 Mar '23

30 Mar '23

If you’ve been meaning to write release notes for your library for the 1.82.0 release, now is the time to do it. ;-) — Marshall

1 0

Re: [boost] Master branch is now open for bug fixes
by Ruben Perez 30 Mar '23

30 Mar '23

On Thu, 16 Mar 2023 at 16:38, Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > > The master branch is now open for bug fixes and documentation changes. I'd like to merge a UB fix to master for Boost.MySQL. It affects only debug builds. Not critical, but may hit some platforms. Discovered during development of new code. https://github.com/boostorg/mysql/pull/136 Thanks, Ruben.

2 1

Re: [boost] Master branch is now open for bug fixes
by Mojca Miklavec 30 Mar '23

30 Mar '23

On Thu, 16 Mar 2023 at 16:38, Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > > The master branch is now open for bug fixes and documentation changes. > Other changes by release manager permission, as described in > https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> I would be really grateful if the following patch (or an alternative resolution for the reported warning/error) could be included in the final release: https://github.com/boostorg/thread/pull/382 (The only other warning we get in our project is https://github.com/boostorg/container/issues/234, but I'm not sure if one is allowed to modify dlmalloc_ext_2_8_6.c.) Quite some other warnings that we've been running into in 1.80 have disappeared in the meantime: thank you very much for that. Thank you very much, Mojca

1 0

Re: [boost] boost-1.82.0.beta1 tag looks wrong
by Marshall Clow 30 Mar '23

30 Mar '23

On Mar 29, 2023, at 8:57 AM, Peter Dimov via Boost <boost(a)lists.boost.org> wrote: > > commit ee18548b1eb68a592d0980611b5f96216ee71a2d (tag: boost-1.82.0.beta1) > Author: Automated Commit <automated(a)calamity.org.uk> > Date: Thu Mar 9 00:00:15 2023 +0000 > > Update multiprecision from develop > > Looks like the boost-1.82.0.beta1 tag points to develop rather than master. I think you’re right. The tag on the super project points to develop, and the one(s) on the sub-project all point to master. — Marshall

1 0

boost-1.82.0.beta1 tag looks wrong
by Peter Dimov 29 Mar '23

29 Mar '23

commit ee18548b1eb68a592d0980611b5f96216ee71a2d (tag: boost-1.82.0.beta1) Author: Automated Commit <automated(a)calamity.org.uk> Date: Thu Mar 9 00:00:15 2023 +0000 Update multiprecision from develop Looks like the boost-1.82.0.beta1 tag points to develop rather than master.

1 0

Re: [boost] Master branch is now open for bug fixes
by Jeff Trull 29 Mar '23

29 Mar '23

I'd like to merge a UB fix to master. It has (so far) not produced nasal demons, but is triggering checkers in projects that depend on Wave. https://github.com/boostorg/wave/pull/185 On Thu, Mar 16, 2023 at 8:38 AM Marshall Clow via Boost < boost(a)lists.boost.org> wrote: > The master branch is now open for bug fixes and documentation changes. > Other changes by release manager permission, as described in > > https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy < > https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> > > The next deadline: On April 5th, master closes for all changes. > > As always, the calendar is at https://www.boost.org/development/ < > https://www.boost.org/development/> > > — Marshall > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

2 1

Re: [boost] Master branch is now open for bug fixes
by Joaquin M López Muñoz 28 Mar '23

28 Mar '23

El 27/03/2023 a las 19:39, Peter Dimov via Boost escribió: > Joaquin M López Muñoz wrote: >> El 16/03/2023 a las 16:38, Marshall Clow via Boost escribió: >>> The master branch is now open for bug fixes and documentation changes. >>> Other changes by release manager permission, as described in >>> https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy >> Hi, I'd like to commit the following changes: >> >> * multi_index: removal of foreach and serialization from dependencies listed >> in CMakeLists.txt: >> https://github.com/boostorg/multi_index/commit/b6d5c88629d3ca3b0822e >> 87629c28ebf151c6a9e >> https://github.com/boostorg/multi_index/commit/0e55b4878952375c8f8c0 >> 0b6dc6964423644970e >> >> * flyweight: removal of serialization from dependencies listed in >> CMakeLists.txt: >> https://github.com/boostorg/flyweight/commit/b37873c46902f06d6c131a5 >> 25493ff6d29180efa > As a general reminder to everyone, if you make changes that add or remove > dependencies, and your CMakeLists.txt file is generated by `boostdep --cmake`, > and contains no further changes, you should regenerate it (by replacing it with > the output of `boostdep --cmake my_library`.) Thanks for the tip, I've just run boostdep and results coincide with what there's already on the CML files. Marshall, OK to merge to master? Joaquín M López Muñoz

2 1

Re: [boost] [scope] Proposing Boost.Scope
by Dominique Devienne 28 Mar '23

28 Mar '23

On Wed, Mar 22, 2023 at 2:41 AM Andrey Semashev via Boost < boost(a)lists.boost.org> wrote: > https://github.com/Lastique/scope Hi. Maybe you should tag your library on GitHub, so it can be easily found, among the several which "compete" with it. Like those listed at the link below: https://github.com/topics/scope-guard?l=c%2B%2B One in particular (https://github.com/offa/scope-guard) refers to the WG21 paper. PS: Actually, I wonder whether Boost Libraries in general use GH tagging much.

2 1

Re: [boost] Master branch is now open for bug fixes
by Peter Dimov 27 Mar '23

27 Mar '23

Joaquin M López Muñoz wrote: > El 16/03/2023 a las 16:38, Marshall Clow via Boost escribió: > > The master branch is now open for bug fixes and documentation changes. > > Other changes by release manager permission, as described in > > https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy > > Hi, I'd like to commit the following changes: > > * multi_index: removal of foreach and serialization from dependencies listed > in CMakeLists.txt: > https://github.com/boostorg/multi_index/commit/b6d5c88629d3ca3b0822e > 87629c28ebf151c6a9e > https://github.com/boostorg/multi_index/commit/0e55b4878952375c8f8c0 > 0b6dc6964423644970e > > * flyweight: removal of serialization from dependencies listed in > CMakeLists.txt: > https://github.com/boostorg/flyweight/commit/b37873c46902f06d6c131a5 > 25493ff6d29180efa As a general reminder to everyone, if you make changes that add or remove dependencies, and your CMakeLists.txt file is generated by `boostdep --cmake`, and contains no further changes, you should regenerate it (by replacing it with the output of `boostdep --cmake my_library`.)

1 0

Re: [boost] Master branch is now open for bug fixes
by Joaquin M López Muñoz 27 Mar '23

27 Mar '23

El 16/03/2023 a las 16:38, Marshall Clow via Boost escribió: > The master branch is now open for bug fixes and documentation changes. > Other changes by release manager permission, as described in > https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy Hi, I'd like to commit the following changes: * multi_index: removal of foreach and serialization from dependencies listed in CMakeLists.txt: https://github.com/boostorg/multi_index/commit/b6d5c88629d3ca3b0822e87629c2… https://github.com/boostorg/multi_index/commit/0e55b4878952375c8f8c00b6dc69… * flyweight: removal of serialization from dependencies listed in CMakeLists.txt: https://github.com/boostorg/flyweight/commit/b37873c46902f06d6c131a525493ff… Thank you! Joaquín M López Muñoz

1 0

Re: [boost] Master branch is now open for bug fixes
by Marshall Clow 27 Mar '23

27 Mar '23

On Mar 27, 2023, at 6:04 AM, Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > > On 3/16/23 18:38, Marshall Clow via Boost wrote: >> The master branch is now open for bug fixes and documentation changes. >> Other changes by release manager permission, as described in >> https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> > > I would like to merge the following commit to Boost.Log master: > > https://github.com/boostorg/log/commit/051f69658971fab5ceccd6bd24b057dd24a2… > > This is not a functional change, it simply fixes a typo in a private > class name. Go ahead. — Marshall

1 0

Re: [boost] Master branch is now open for bug fixes
by Andrey Semashev 27 Mar '23

27 Mar '23

On 3/16/23 18:38, Marshall Clow via Boost wrote: > The master branch is now open for bug fixes and documentation changes. > Other changes by release manager permission, as described in > https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy <https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy> I would like to merge the following commit to Boost.Log master: https://github.com/boostorg/log/commit/051f69658971fab5ceccd6bd24b057dd24a2… This is not a functional change, it simply fixes a typo in a private class name.

1 0

Re: [boost] [release] Boost 1.82.0 beta 1 released
by Andrey Semashev 27 Mar '23

27 Mar '23

On 3/15/23 18:38, Marshall Clow via Boost wrote: > Boost release 1.82.0 beta 1 is now available at: > https://boostorg.jfrog.io/artifactory/main/beta/1.82.0.beta1/source/ > > The SHA256 checksums are: > efe17bea3f0b2c11f34828f37d5777f30eb6fef57af355c6a6664b08a4339999 boost_1_82_0_b1.7z > 0af2a60f76abb4f411b1bd9c1a553f64454d9414990e8cc12f02f3b431e2ac45 boost_1_82_0_b1.tar.gz > 495b2ae2f6970ea1e635f80222d9f6978148496cdd163e87c37cdd6de3b5ccfc boost_1_82_0_b1.zip > edf4cb9e8e5a14412b91311438478ef6ce12afe2a54714eb2f0632a454c3d8d5 boost_1_82_0_b1.tar.bz2 > > Release notes (still need updates): > https://www.boost.org/users/history/version_1_82_0.html > > Please try the beta and report any problems you encounter. There is a bug in Boost.MultiIndex CMakeLists.txt, although it may not affect the monolithic release tarball. The CMakeLists.txt lists a dependency on Boost::foreach target while no Boost.MultiIndex headers require it. This causes CI failures in Boost.Log[1] because boostdep does not find the dependency from headers and doesn't checkout Boost.ForEach git repository, which makes CMake to fail to resolve the dependency later. [1]: https://github.com/boostorg/log/actions/runs/4531415733/jobs/7981536579

1 0

Re: [boost] [release] Boost 1.82.0 beta 1 released
by Andrey Semashev 27 Mar '23

27 Mar '23

On 3/15/23 18:38, Marshall Clow via Boost wrote: > Boost release 1.82.0 beta 1 is now available at: > https://boostorg.jfrog.io/artifactory/main/beta/1.82.0.beta1/source/ > > The SHA256 checksums are: > efe17bea3f0b2c11f34828f37d5777f30eb6fef57af355c6a6664b08a4339999 boost_1_82_0_b1.7z > 0af2a60f76abb4f411b1bd9c1a553f64454d9414990e8cc12f02f3b431e2ac45 boost_1_82_0_b1.tar.gz > 495b2ae2f6970ea1e635f80222d9f6978148496cdd163e87c37cdd6de3b5ccfc boost_1_82_0_b1.zip > edf4cb9e8e5a14412b91311438478ef6ce12afe2a54714eb2f0632a454c3d8d5 boost_1_82_0_b1.tar.bz2 > > Release notes (still need updates): > https://www.boost.org/users/history/version_1_82_0.html > > Please try the beta and report any problems you encounter. There is a bug in Boost.ASIO that prevents Boost.Log from compiling with gcc 4.4 and clang 3.5. The bug is in BOOST_ASIO_ASSUME definition: https://github.com/boostorg/asio/blob/boost-1.82.0.beta1/include/boost/asio… 1. gcc 4.4 does not support __builtin_unreachable, which makes the __GNUC__ branch definition to fail. 2. clang 3.5 doesn't support __builtin_assume and uses the last fallback option. There, BOOST_ASIO_ASSUME is defined without arguments, meaning it expands to incorrect code like `(void)0(base != 0)`. GitHub is dead for me ATM, so I can't create a PR.

1 0

Add toolset=msvc-143 (Visual Studio 2022) to B2 user manual
by Kenneth Porter 27 Mar '23

27 Mar '23

I was looking up the syntax to add MSVS 2022 to my library build script and the online manual lacks it: <https://www.boost.org/doc/libs/1_81_0/tools/build/doc/html/index.html#bbv2.…> I don't know where the repo is for this page or I'd file an issue. Perhaps include the repo link at the top or bottom of the page or in an HTML comment?

1 0

Re: [boost] [scope] Proposing Boost.Scope
by Klemens Morgenstern 27 Mar '23

27 Mar '23

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(a)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 > <experimental/scope> 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 <experimental/scope>, 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 >

2 2

Re: [boost] [release] Boost 1.82.0 beta 1 released
by Ruben Perez 26 Mar '23

26 Mar '23

On Wed, 15 Mar 2023 at 16:28, Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > > Boost release 1.82.0 beta 1 is now available at: > https://boostorg.jfrog.io/artifactory/main/beta/1.82.0.beta1/source/ [...] > Please try the beta and report any problems you encounter. I have tried building the beta on Ubuntu 22.04, clang-15 with libc++ with no errors. Building a sample program using the new Boost.MySQL works as intended. Regards, Ruben.

1 0

Boost configuration problem
by Raivo Rebane 24 Mar '23

24 Mar '23

Hello, May be I am in wrong list, but I didnt get answer for week from bugs list. May be anybody can help me ? I got following error from boost configuration and I can't go forward CMake gives configuration errors : CMake Error at C:/Users/Raivo/miniconda3/Library/lib/cmake/Boost-1.78.0/BoostConfig.cmake:141 (find_package): Found package configuration file: C:/Users/Raivo/miniconda3/Library/lib/cmake/boost_filesystem-1.78.0/boost_filesystem-config.cmake but it set boost_filesystem_FOUND to FALSE so package "boost_filesystem" is considered to be NOT FOUND. Reason given by package: No suitable build variant has been found. The following variants have been tried and rejected: * boost_filesystem.lib (shared, Boost_USE_STATIC_LIBS=ON) Still Boost is useless for me as I wanted to build Point CLoud Lib, bud CMake stops on these errors. How to overcome of this error or what I have to do to go forwwsrd ? Regards Raivo

1 0

PSA: GitHub public RSA key has changed
by Andrey Semashev 24 Mar '23

24 Mar '23

Hi, This is just a heads up that GitHub public RSA key has changed. If you're using ssh with an RSA key to access GitHub, you may see errors saying that remote host identification has changed. The change was made on March 24. You can find more details and instructions to update your locally cached key in the link below. https://github.blog/2023-03-23-we-updated-our-rsa-ssh-host-key/ PS: This may affect CI runs if they are configured with the ssh-key option, but I don't think any of the Boost libraries are.

1 0

introduce boost::utility::ios.hpp
by Gero Peterhoff 23 Mar '23

23 Mar '23

For easy handling of various stream operations I would like to provide a small library: * queries stream properties * supports defaultfloat/hexfloat * provides conversions for stream::floatfield <-> FP std::chars_format in C++17 + getter/setter + std::setfloat * provides conversions for numeric output of u/int8_t * small stuff like std::tab Summa summarum This makes it much more pleasant to work with than manually fiddling around with stream::flags. thx Gero

1 0

Re: [boost] [scope] Proposing Boost.Scope
by Andrey Semashev 22 Mar '23

22 Mar '23

On 3/22/23 16:01, Daniela Engert via Boost wrote: > Am 22.03.2023 um 13:34 schrieb Andrey Semashev via Boost: >> On 3/22/23 14:23, Daniela Engert via Boost wrote: >>> Am 22.03.2023 um 11:24 schrieb Andrey Semashev via Boost: >>>> [[nodiscard]] is not usable here as there's nothing to apply it to, as >>>> we're talking about the scope guard constructor. >>> [[nodiscard]] is highly desirable here. You can apply the attribute to >>> class types (and thus their constructors) and avoid the (typically >>> unwanted) immediate destruction of pr-values. Manager classes should be >>> marked [[nodiscard]] by habit. >> I didn't know you can apply [[nodiscard]] to classes, but apparently you >> can. I suppose, I could mark scope guards with it, but I'm not sure if >> limiting the use cases would be desirable. For example, should we >> consider the following a wrong use of the scope guard? >> >> auto foo() >> { >> // do something useful and return the epilogue >> return scope_exit([] { whatever }); >> } >> >> void bar() >> { >> foo(); // do what foo() does, plus the epilogue >> // ... >> } >> >> void zoo() >> { >> auto epilogue = foo(); // do what foo() does, and delay the epilogue >> // ... >> } > > Suppose you mark class scope_exit with [[nodiscard], then the return > statement in foo() will construct a temporary scope_exit in its return > expression and pass it out of function foo. This by itself is a use of > the temporary and doesn't trigger a compiler warning. If you want to > prevent the immediate destruction of the returned scope_exit in bar(), > then you need to mark foo() as [[nodiscard]]. But if you consider this a > valid use case (albeit a strange one) then you might want to mark foo() > as [[maybe_unused]] to communicate this intent. Remember: the return > object of foo() is conceptually different from the object created in the > return expression of foo(). I did not mean to mark either of the functions as [[nodiscard]], I was considering marking scope_exit as [[nodiscard]], which, I think, is what you suggested. If it was marked as such, the code in bar() would emit a warning, which I'm not sure is a good thing. For now I'm leaning towards not marking the scope guards with [[nodiscard]] as I don't like limiting the use cases of these classes.

1 0

Re: [boost] [scope] Proposing Boost.Scope
by Daniela Engert 22 Mar '23

22 Mar '23

Am 22.03.2023 um 13:34 schrieb Andrey Semashev via Boost: > On 3/22/23 14:23, Daniela Engert via Boost wrote: >> Am 22.03.2023 um 11:24 schrieb Andrey Semashev via Boost: >>> [[nodiscard]] is not usable here as there's nothing to apply it to, as >>> we're talking about the scope guard constructor. >> [[nodiscard]] is highly desirable here. You can apply the attribute to >> class types (and thus their constructors) and avoid the (typically >> unwanted) immediate destruction of pr-values. Manager classes should be >> marked [[nodiscard]] by habit. > I didn't know you can apply [[nodiscard]] to classes, but apparently you > can. I suppose, I could mark scope guards with it, but I'm not sure if > limiting the use cases would be desirable. For example, should we > consider the following a wrong use of the scope guard? > > auto foo() > { > // do something useful and return the epilogue > return scope_exit([] { whatever }); > } > > void bar() > { > foo(); // do what foo() does, plus the epilogue > // ... > } > > void zoo() > { > auto epilogue = foo(); // do what foo() does, and delay the epilogue > // ... > } Suppose you mark class scope_exit with [[nodiscard], then the return statement in foo() will construct a temporary scope_exit in its return expression and pass it out of function foo. This by itself is a use of the temporary and doesn't trigger a compiler warning. If you want to prevent the immediate destruction of the returned scope_exit in bar(), then you need to mark foo() as [[nodiscard]]. But if you consider this a valid use case (albeit a strange one) then you might want to mark foo() as [[maybe_unused]] to communicate this intent. Remember: the return object of foo() is conceptually different from the object created in the return expression of foo().

1 0

Re: [boost] [scope] Proposing Boost.Scope
by Andrey Semashev 22 Mar '23

22 Mar '23

On 3/22/23 14:23, Daniela Engert via Boost wrote: > Am 22.03.2023 um 11:24 schrieb Andrey Semashev via Boost: >> [[nodiscard]] is not usable here as there's nothing to apply it to, as >> we're talking about the scope guard constructor. > > [[nodiscard]] is highly desirable here. You can apply the attribute to > class types (and thus their constructors) and avoid the (typically > unwanted) immediate destruction of pr-values. Manager classes should be > marked [[nodiscard]] by habit. I didn't know you can apply [[nodiscard]] to classes, but apparently you can. I suppose, I could mark scope guards with it, but I'm not sure if limiting the use cases would be desirable. For example, should we consider the following a wrong use of the scope guard? auto foo() { // do something useful and return the epilogue return scope_exit([] { whatever }); } void bar() { foo(); // do what foo() does, plus the epilogue // ... } void zoo() { auto epilogue = foo(); // do what foo() does, and delay the epilogue // ... }

1 0

Re: [boost] [scope] Proposing Boost.Scope
by Daniela Engert 22 Mar '23

22 Mar '23

Am 22.03.2023 um 11:24 schrieb Andrey Semashev via Boost: > On 3/22/23 12:38, Dominique Devienne wrote: > >> Like [[nodiscard]] with an alternate form like `auto guard = >> scope_fail(...);` ? >> I guess that requires move'ability, which might not be desirable? > `auto guard = scope_fail(...);` would work, as scope_fail is moveable. > With C++17, I think, you are even guaranteed to elide the move constructor. With C++17 and guaranteed copy elision you can return non-copyable, non-movable objects. > [[nodiscard]] is not usable here as there's nothing to apply it to, as > we're talking about the scope guard constructor. [[nodiscard]] is highly desirable here. You can apply the attribute to class types (and thus their constructors) and avoid the (typically unwanted) immediate destruction of pr-values. Manager classes should be marked [[nodiscard]] by habit. Ciao Dani

1 0

Re: [boost] [scope] Proposing Boost.Scope
by Dominique Devienne 22 Mar '23

22 Mar '23

On Wed, Mar 22, 2023 at 10:04 AM Andrey Semashev via Boost < boost(a)lists.boost.org> wrote: > error_code ec; > scope_fail guard( > [&] { std::cout << "Failure" << std::endl; }, > [&ec] { return !!ec; }); > Having made the dumb mistake of writing once or twice `scope_fail(...);` instead of `scope_fail guard(...);`, is there a way to prevent that? Like [[nodiscard]] with an alternate form like `auto guard = scope_fail(...);` ? I guess that requires move'ability, which might not be desirable?

2 1