March 2023 - Boost - lists.boost.org

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 200

Boost Governance?
by René Ferdinand Rivera Morell 09 Aug '24

09 Aug '24

A disclaimer: I write this solely as a Boost Library author. And not in any other capacity or representing any other interest. It's now been at least a year since Boost switched from the Software Freedom Conservancy to the Boost Foundation for its governance organization. But have people noticed any difference? Did you know that switch happened? Did you know that they held an election for the Board of Directors and for the Officers? Do you know when that election happened? Do you know who got elected? Do you know how they were selected? Do you know what their responsibilities are? Do you know what their bylaws are? Do you know their financials? More importantly: Did you answer "no" to any of those questions? As a library author, I can say I definitely answered no to many of those questions. This is a problem. As authors, without asking, we should know those answers from the organization that governs our work. We should have input into how that organization governs. In other words, we deserve open and transparent governance; not the closed and opaque status quo. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

10 10

Paul Bristow
by John Maddock 08 Aug '24

08 Aug '24

I've just heard that Paul Bristow who helped so much with the development of Boost.Math and indeed many other libraries, passed away peacefully last week. RIP Paul. Much missed. John.

7 7

Library proposal - indexed_array
by Julien Blanc 12 Oct '23

12 Oct '23

Hi, I've written and released a (rather small) library which allows defining arrays with arbitrary index mechanisms (hence the name, indexed_array). This especially allows indexing with scoped enums, use non zero-starting indexes, or use sparse indexes. This is not a view, but an array in the sense that it owns the data, and provides the same guarantees and functionalities as std::array, such as triviality propagation, being able to reside in read-only program sections, etc. It also supports multidimensional indexing, and provides an indexed_span template class to access lower dimension content (which can be used outside indexed_array). Finally, it provides an opt-in safer way to initialize the array content, which is especially useful when using complex and/or changing indexing schemes (like based on externally generated files). The library is available here: https://github.com/Julien-Blanc-tgcm/indexed_array And the doc is here: https://julien-blanc-tgcm.github.io/indexed_array/ It requires C++17 and mp11, and has first-class support for describe-d enums. If there is some interest, i'd like to propose it for inclusion in boost. So i'm looking for people who would endorse it. Thanks and best regards, Julien

8 24

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

Re: [boost] [scope] Proposing Boost.Scope
by Darrell Wright 22 Mar '23

22 Mar '23

One thing I learned in my own replacement is that exit_success is heavily penalized on MSVC, even when there is no possible exception, because of the call to uncaught_exceptions that isn’t optimized. It’s a good thing to document, if not already, as it is surprising. Darrell > On Mar 21, 2023, at 21:41, 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

1 0

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

22 Mar '23

On Mar 21, 2023, at 6:34 PM, Klemens Morgenstern via Boost <boost(a)lists.boost.org> wrote: > > I would like to ask permission to merge this minor fix: > https://github.com/boostorg/beast/pull/2659 <https://github.com/boostorg/beast/pull/2659> > If the tests have cycled, and you’re happy with the results, then go ahead. — Marshall

1 0

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

22 Mar '23

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.

1 0

Re: [boost] Master branch is now open for bug fixes
by Klemens Morgenstern 22 Mar '23

22 Mar '23

I would like to ask permission to merge this minor fix: https://github.com/boostorg/beast/pull/2659 On Wed, Mar 22, 2023 at 7:44 AM Marshall Clow via Boost < boost(a)lists.boost.org> wrote: > > > > On Mar 21, 2023, at 10:48 AM, Antony Polukhin via Boost < > boost(a)lists.boost.org> wrote: > > > > On Thu, Mar 16, 2023, 18: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> > >> > > > > Sorry, I've misread the message and applied a "bug fix" without reading > the > > wiki, where "Code changes and fixes" should be merged only after release > > manager permission. > > > > May I keep the bugfix > > > https://github.com/boostorg/stacktrace/commit/d904d26f4f5998fc1488e964a37e6… > > for the stacktrace merged to master branch? > > > > Thanks for letting us know. > The commit looks fine to me. > > — Marshall > > > > > The fix was in develop for two months and it switches > > backtrace_create_state into thread safe mode if platform supports > > multithreading. > > > >> > > > > _______________________________________________ > > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

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

21 Mar '23

> On Mar 21, 2023, at 10:48 AM, Antony Polukhin via Boost <boost(a)lists.boost.org> wrote: > > On Thu, Mar 16, 2023, 18: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> >> > > Sorry, I've misread the message and applied a "bug fix" without reading the > wiki, where "Code changes and fixes" should be merged only after release > manager permission. > > May I keep the bugfix > https://github.com/boostorg/stacktrace/commit/d904d26f4f5998fc1488e964a37e6… > for the stacktrace merged to master branch? > Thanks for letting us know. The commit looks fine to me. — Marshall > The fix was in develop for two months and it switches > backtrace_create_state into thread safe mode if platform supports > multithreading. > >> > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Master branch is now open for bug fixes
by Antony Polukhin 21 Mar '23

21 Mar '23

On Thu, Mar 16, 2023, 18: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> > Sorry, I've misread the message and applied a "bug fix" without reading the wiki, where "Code changes and fixes" should be merged only after release manager permission. May I keep the bugfix https://github.com/boostorg/stacktrace/commit/d904d26f4f5998fc1488e964a37e6… for the stacktrace merged to master branch? The fix was in develop for two months and it switches backtrace_create_state into thread safe mode if platform supports multithreading. >

1 0

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

21 Mar '23

On Mar 21, 2023, at 8:59 AM, Samuel DEBIONNE via Boost <boost(a)lists.boost.org> wrote: > > Hello, > I would like to merge a "missing include" fix from Boost.GIL to master: > > https://github.com/boostorg/gil/pull/729 Go ahead — Marshall > > Thank you, > Samuel > On 16/03/2023 16:43, 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> >> 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 > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Master branch is now open for bug fixes
by Samuel DEBIONNE 21 Mar '23

21 Mar '23

Hello, I would like to merge a "missing include" fix from Boost.GIL to master: https://github.com/boostorg/gil/pull/729 Thank you, Samuel On 16/03/2023 16:43, 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> > > 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

1 0

Re: [boost] Need Volunteers for Docs!
by Ruben Perez 19 Mar '23

19 Mar '23

On Sat, 18 Mar 2023, 01:55 Vinnie Falco via Boost, <boost(a)lists.boost.org> wrote: > > Documentation has been a long-running complaint of users and authors. > The look of it, the content of it, and the way that people find it. We > are looking to resolve all of that and we've made quite a lot of > progress but we need help. There's a ton of work going into the > infrastructure and website right now so if you want to be a part of it > please speak up! > You know my obsession with docs, so I volunteer. Please let me know how can I help. Ruben. > >

2 1

Re: [boost] Need Volunteers for Docs!
by Vinnie Falco 18 Mar '23

18 Mar '23

On Fri, Mar 17, 2023 at 6:07 PM Klemens Morgenstern via Boost <boost(a)lists.boost.org> wrote: > I've been writing the occasional post on cppalliance.org, should that go to > boost instead? Or should boost operate like an aggregator? There's no facility for blogging yet but there will be on the new Boost website (and it will use Asciidoc). This will take a while though since it is not a planned feature for the initial release. This will also come with a way to post off-site links (like an aggregator) but since https://cpp.al is not receiving heavy traffic it would make more sense to migrate the blog content from there to the new boost.org. Thanks

1 0

Re: [boost] Need Volunteers for Docs!
by Klemens Morgenstern 18 Mar '23

18 Mar '23

I've been writing the occasional post on cppalliance.org, should that go to boost instead? Or should boost operate like an aggregator? On Sat, Mar 18, 2023 at 8:55 AM Vinnie Falco via Boost < boost(a)lists.boost.org> wrote: > All: > > We are working on the User's Guide which is for people who want to use > Boost, and we are working on the Contributor's guide which is for > people who want to contribute to Boost. This includes authors, > maintainers, reviewers, review managers, review wizards, release > managers, contributors, testers, basically everyone who is changing > the state of our repositories somehow. > > These manuals are written in Asciidoc, but we need volunteers who can > jump in and start producing results right away. Most of the existing > site content has been ported to markdown and it needs editing and > sorting into a table of contents. The Getting Started instructions > which go into the release are in pretty rough shape and need editing. > > Documentation has been a long-running complaint of users and authors. > The look of it, the content of it, and the way that people find it. We > are looking to resolve all of that and we've made quite a lot of > progress but we need help. There's a ton of work going into the > infrastructure and website right now so if you want to be a part of it > please speak up! > > This is a sample of where we are going with it (the stylesheets have > not been worked on yet): > > https://antora.cppalliance.org/doc/html/mp11/mp11/list.html > > https://antora.cppalliance.org/doc/html/contributor-manual/intro.html > > Thank you for considering it ! > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Need Volunteers for Docs!
by Vinnie Falco 18 Mar '23

18 Mar '23

All: We are working on the User's Guide which is for people who want to use Boost, and we are working on the Contributor's guide which is for people who want to contribute to Boost. This includes authors, maintainers, reviewers, review managers, review wizards, release managers, contributors, testers, basically everyone who is changing the state of our repositories somehow. These manuals are written in Asciidoc, but we need volunteers who can jump in and start producing results right away. Most of the existing site content has been ported to markdown and it needs editing and sorting into a table of contents. The Getting Started instructions which go into the release are in pretty rough shape and need editing. Documentation has been a long-running complaint of users and authors. The look of it, the content of it, and the way that people find it. We are looking to resolve all of that and we've made quite a lot of progress but we need help. There's a ton of work going into the infrastructure and website right now so if you want to be a part of it please speak up! This is a sample of where we are going with it (the stylesheets have not been worked on yet): https://antora.cppalliance.org/doc/html/mp11/mp11/list.html https://antora.cppalliance.org/doc/html/contributor-manual/intro.html Thank you for considering it !

1 0

Re: [boost] announcing boost.async
by Richard Hodges 17 Mar '23

17 Mar '23

On Fri, 17 Mar 2023 at 16:22, Klemens Morgenstern via Boost < boost(a)lists.boost.org> wrote: > Hi, > > I've been working on a C++20 coroutine library, called `async`, > which is meant to be for C++ what asyncio is for python or generic > async/await is for javascript. > It's meant to be a framework for single threaded coroutine applications. > You are doing the Lord's work. > > It provides coroutine types, such as promises, tasks and generators to > model async operations, > channels for inter-coroutine communication and functions > like select, gather & join to wait or combine multiple awaitables. > > It's asio-based, i.e. uses asio::io_context as its event-loop and can > co_await any asio operation. > > As this is a very complex domain, I really would be happy to have some > users. > This will help me to improve documentation & come up with more > example ideas. > > Docs: https://klemens.dev/async > Repo: https://github.com/klemens-morgenstern/async > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

announcing boost.async
by Klemens Morgenstern 17 Mar '23

17 Mar '23

Hi, I've been working on a C++20 coroutine library, called `async`, which is meant to be for C++ what asyncio is for python or generic async/await is for javascript. It's meant to be a framework for single threaded coroutine applications. It provides coroutine types, such as promises, tasks and generators to model async operations, channels for inter-coroutine communication and functions like select, gather & join to wait or combine multiple awaitables. It's asio-based, i.e. uses asio::io_context as its event-loop and can co_await any asio operation. As this is a very complex domain, I really would be happy to have some users. This will help me to improve documentation & come up with more example ideas. Docs: https://klemens.dev/async Repo: https://github.com/klemens-morgenstern/async

1 0

Re: [boost] improve <boost/math/constants.hpp>
by Gero Peterhoff 16 Mar '23

16 Mar '23

I forgot my test case int main() { std::cout << std::setprecision(100); std::cout << "boost pi" << std::endl; { const auto pi = boost::math::constants::pi<std::float16_t>(); std::cout << pi << std::endl; } { constexpr auto pi = boost::math::constants::pi<std::float128_t>(); std::cout << pi << std::endl; } { constexpr auto pi = boost::math::constants::pi<boost::multiprecision::float128>(); std::cout << pi << std::endl; } { const auto pi = boost::math::constants::pi<boost::multiprecision::cpp_bin_float_100>(); std::cout << pi << std::endl; } std::cout << "my pi" << std::endl; { constexpr auto pi = boost::math::constants::my_pi<std::float16_t>(); std::cout << pi << std::endl; } { constexpr auto pi = boost::math::constants::my_pi<std::float128_t>(); std::cout << pi << std::endl; } { constexpr auto pi = boost::math::constants::my_pi<boost::multiprecision::float128>(); std::cout << pi << std::endl; } { const auto pi = boost::math::constants::my_pi<boost::multiprecision::cpp_bin_float_100>(); std::cout << pi << std::endl; } return EXIT_SUCCESS; } boost pi 3.140625000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 3.141592653589793238462643383279502797479068098137295573004504331874296718662975536062731407582759857 3.141592653589793238462643383279502797479068098137295573004504331874296718662975536062731407582759857 3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117068 my pi 3.140625000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 3.141592653589793238462643383279502797479068098137295573004504331874296718662975536062731407582759857 3.141592653589793238462643383279502797479068098137295573004504331874296718662975536062731407582759857 3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117068

1 0

Re: [boost] improve <boost/math/constants.hpp>
by Gero Peterhoff 16 Mar '23

16 Mar '23

Am 11.03.23 um 11:44 schrieb John Maddock via Boost: > On 10/03/2023 21:12, Gero Peterhoff via Boost wrote: - The support for XX_v is omitted. - Additional macros BOOST_FLOATxx_C_OR_ZERO are needed. - boost::multiprecision::float128 is now constexpr if possible. > Off the top of my head I see two main correctness issues: > * Your code introduces *double rounding* for float/double (and maybe long double) types, as a result the constants for these types will no longer guarantee last digit accuracy. This is a deal breaker for me> I am not sure if this is actually true. When testing with pi the results were identical. If this should be generally so (testing) we can save the helper macros BOOST_FLOATxx_C_OR_ZERO and use the general version. In the code the general version is available, but commented out. > * For multiprecision types with more digits than we can reasonably store in a string your constants will have insufficient accuracy (cached runtime calculation is needed in this case). Instead of lexical_cast, the constructor(sting) is now used - had overlooked that. Is the accuracy sufficient? > * It's also lacking some "nice to have" features, for example, you have all UDT types going the lexical_cast route, but if the type can be constructed from a builtin type with sufficient precision, then the code is more efficient and constexpr that way. For example with boost::multiprecision::float128. As said boost::multiprecision::float128 works now. Are there any other cases? Exactly with boost::multiprecision::float128 it is noticed negatively that there are 3 code paths: - gcc (BOOST_MP_USE_FLOAT128) - intel (BOOST_MP_USE_QUAD) - in general This was also the reason for my other posting - quadmath as a standalone library. Then there would be only 2 code paths and the quadmath lib could be implemented more understandable. Eg there is in cstdfloat_iostream.hpp AND cstdfloat_cmath.hpp the stream operator<<. This is completely unnecessary effort. You have expressed concerns that with these measures the code would have to be adapted - which nobody likes to do. But in the train with C++23-FP types this must be done anyway - then please correctly. Gero

1 0

Re: [boost] Master branch is now open for bug fixes
by Glen Fernandes 16 Mar '23

16 Mar '23

On Thursday, March 16, 2023, John Maddock via Boost <boost(a)lists.boost.org> wrote: > > I'd like to merge two bug fixes from Multiprecision into master if > possible: > > * This one is a flat out correctness-bug that really should go in: > https://github.com/boostorg/multiprecision/pull/542 > > * This one is a more nice to have fix to the conversion operators: > https://github.com/boostorg/multiprecision/pull/543 > > > Go ahead Glen

1 0

Re: [boost] Master branch is now open for bug fixes
by John Maddock 16 Mar '23

16 Mar '23

On 16/03/2023 15: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'd like to merge two bug fixes from Multiprecision into master if possible: * This one is a flat out correctness-bug that really should go in: https://github.com/boostorg/multiprecision/pull/542 * This one is a more nice to have fix to the conversion operators: https://github.com/boostorg/multiprecision/pull/543 In both cases the one CI failure, is a network timeout on the drone runner pulling Boost down. Thanks, John.

1 0

Master branch is now open for bug fixes
by Marshall Clow 16 Mar '23

16 Mar '23

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

1 0

Re: [boost] [Release] Master branch is closed for beta
by Andrey Semashev 16 Mar '23

16 Mar '23

On 3/9/23 17:19, Marshall Clow via Boost wrote: > Master is closed for all changes. > > See the release schedule at: https://www.boost.org/development/index.html <https://www.boost.org/development/index.html> Is the master branch open now?

1 0

[release] Boost 1.82.0 beta 1 released
by Marshall Clow 15 Mar '23

15 Mar '23

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. Thanks to everyone who contributed to the release. -- Boost Release Team

1 0

Re: [boost] Reducing dependency on Boost.Regex
by Boris Kolpackov 15 Mar '23

15 Mar '23

Robert Ramey via Boost <boost(a)lists.boost.org> writes: > On 3/13/23 5:54 AM, Boris Kolpackov via Boost wrote: > > > This implicit "if you don't include the header then you don't need to > > link the dependency" approach doesn't scale well to cases where Boost is > > split into individual packages which are managed by a package manager. > > Right. This is a built-in deficiency of the package manager approach. > Dependencies are dependent upon the actual end user application and cannot > be logically discerned a priori by any package manager. They cannot be "magically" discerned but there can be a mechanism for specifying them explicitly. I don't believe we are disagreeing about the fundamental issues, which is that there needs to be support for optional dependencies. The difference is that you seem to advocate implicit discovery (and ongoing maintenance) of optional dependencies by the end-user (based on linker errors, by carefully studying the documentation, etc) while I advocate having an explicit mechanism in the package manager for the library author to specify which functionality is optional (and that requires optional dependencies) and for the library user to request this optional functionality (and automatically get the required dependencies). We have such a mechanism in build2, in our experience it works well, and we have applied it to the Boost libraries. > Contrary to what one would hope, the package manager is not a panacia > and trying to make it into one is a hopeless quest which leads to > pointless efforts to "eliminate dependencias" and create "standalone" > libraries. That's quite a bizarre perspective, seeing that the main functionality of a package manager is to make management of dependencies easier. It also doesn't match empirical evidence. For example, in Rust it's hard to find a package that doesn't have at least a few dozens dependencies (and more often a few hundreds). If anything, the problem is actually the opposite.

1 0

Re: [boost] v1.81.0 web page: operators library links to utility
by Andrey Semashev 15 Mar '23

15 Mar '23

On 3/15/23 07:04, Gavin Lambert via Boost wrote: > On 15/03/2023 16:33, Brook Milligan wrote: >> I’m not sure who to report this to, but it seems to me that on the >> web page for Boost v1.81.0 docs, the Operators library link is to >> Utility not Operators. > Boost.Operators isn't actually a real library; it's part of > Boost.Utility. But it does have the wrong link. > > For reference: > > - Page: https://www.boost.org/doc/libs/1_81_0/ > - Link target: > https://www.boost.org/doc/libs/1_81_0/libs/utility/operators.htm > - Actual page: > https://www.boost.org/doc/libs/1_81_0/libs/utility/doc/html/utility/utiliti… > > It looks like this broke as of Boost 1.78. libs/utility/operators.htm exists and redirects to doc/html/utility/utilities/operators.html.

1 1

Re: [boost] v1.81.0 web page: operators library links to utility
by Gavin Lambert 15 Mar '23

15 Mar '23

On 15/03/2023 16:33, Brook Milligan wrote: > I’m not sure who to report this to, but it seems to me that on the > web page for Boost v1.81.0 docs, the Operators library link is to > Utility not Operators. Boost.Operators isn't actually a real library; it's part of Boost.Utility. But it does have the wrong link. For reference: - Page: https://www.boost.org/doc/libs/1_81_0/ - Link target: https://www.boost.org/doc/libs/1_81_0/libs/utility/operators.htm - Actual page: https://www.boost.org/doc/libs/1_81_0/libs/utility/doc/html/utility/utiliti… It looks like this broke as of Boost 1.78.

1 0

v1.81.0 web page: operators library links to utility
by Brook Milligan 15 Mar '23

15 Mar '23

I’m not sure who to report this to, but it seems to me that on the web page for Boost v1.81.0 docs, the Operators library link is to Utility not Operators. Cheers, Brook

1 0

Re: [boost] Reducing dependency on Boost.Regex
by Gavin Lambert 15 Mar '23

15 Mar '23

On 15/03/2023 06:35, Robert Ramey wrote: > Right. This is a built-in deficiency of the package manager approach. > Dependencies are dependent upon the actual end user application and > cannot be logically discerned a priori by any package manager. Contrary > to what one would hope, the package manager is not a panacia and trying > to make it into one is a hopeless quest which leads to pointless efforts > to "eliminate dependencias" and create "standalone" libraries. What I imagine is part of the problem is that the package management ecosystem has grown up independently from the component authors -- so the package maintainer runs tools to see "oh, this header file is included, that must be a dependency" because they're less familiar with the *context* of that inclusion than the actual component author, and there aren't even standardized package names let alone a standardized way for the component author to indicate to package tools what things should be considered required vs. optional. There are occasional whispers of something almost like that, in the form of autoconf, pkg-config, or CMakeFiles that can list dependencies, but these aren't universal and can have complex logic based on options. And then there's distinctions between dev and runtime dependencies...

1 0

Re: [boost] Reducing dependency on Boost.Regex
by Robert Ramey 14 Mar '23

14 Mar '23

On 3/13/23 5:54 AM, Boris Kolpackov via Boost wrote: > John Maddock via Boost <boost(a)lists.boost.org> writes: > > This implicit "if you don't include the header then you don't need to > link the dependency" approach doesn't scale well to cases where Boost is > split into individual packages which are managed by a package manager. Right. This is a built-in deficiency of the package manager approach. Dependencies are dependent upon the actual end user application and cannot be logically discerned a priori by any package manager. Contrary to what one would hope, the package manager is not a panacia and trying to make it into one is a hopeless quest which leads to pointless efforts to "eliminate dependencias" and create "standalone" libraries. > When the package manager undertakes to provide a Boost library, it > should come with all the dependencies that could be needed for any > usage scenario, unless certain features are explicitly not enabled > (which is essentially what we have done -- not enabled regex by > default in a bunch of libraries; I suppose we could have instead not > enabled ICU in regex by default). This mini-history illustrates my point above. More thinking is required on this subject. Perhaps the role of the IDE needs to be expanded or ... ? Robert Ramey > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Re: [boost] Reducing dependency on Boost.Regex
by John Maddock 14 Mar '23

14 Mar '23

> There does need to be a way to recognise optional or soft dependencies > though -- a library might include a compatibility header that can > optionally be included if you are also using another library, but this > should not require the other library as a hard dependency. > > If you in turn write a library or app that does use both, then you > depend on both, but they don't depend on each other. > > I think it's ok to put this on the downstream author -- they will try > to build, get a compile error, then add the missing dependency > themselves. > Agreed 100%. The canonical example is serialization: you will most certainly know that you need that library if you intend to serialize and install it anyway, so no need for an automatic dependency. John.

1 0

Re: [boost] Reducing dependency on Boost.Regex
by Gavin Lambert 13 Mar '23

13 Mar '23

On 14/03/2023 01:54, Boris Kolpackov wrote: > This implicit "if you don't include the header then you don't need to > link the dependency" approach doesn't scale well to cases where Boost is > split into individual packages which are managed by a package manager. > When the package manager undertakes to provide a Boost library, it > should come with all the dependencies that could be needed for any > usage scenario, unless certain features are explicitly not enabled > (which is essentially what we have done -- not enabled regex by > default in a bunch of libraries; I suppose we could have instead not > enabled ICU in regex by default). There does need to be a way to recognise optional or soft dependencies though -- a library might include a compatibility header that can optionally be included if you are also using another library, but this should not require the other library as a hard dependency. If you in turn write a library or app that does use both, then you depend on both, but they don't depend on each other. I think it's ok to put this on the downstream author -- they will try to build, get a compile error, then add the missing dependency themselves.

1 0

Re: [boost] Reducing dependency on Boost.Regex
by Francois Kritzinger 13 Mar '23

13 Mar '23

On 2023/03/13 14:07, Andrey Semashev via Boost wrote: > On 3/13/23 15:00, Boris Kolpackov via Boost wrote: >> A quick note on our experience reducing dependency on Boost.Regex >> (and thus ICU) in build2 packages for Boost 1.81.0. Now only the >> following (leaf) libraries unconditionally depend on Boost.Regex: >> >> * Boost.Convert >> * Boost.DLL >> * Boost.Log > > Boost.Log can be configured to use std::regex or Boost.Xpressive as an > alternative to Boost.Regex. However Boost.Log also depends on Boost.Spirit which depends on Boost.Regex so that's a hard dependency.

1 0

Re: [boost] Reducing dependency on Boost.Regex
by Boris Kolpackov 13 Mar '23

13 Mar '23

John Maddock via Boost <boost(a)lists.boost.org> writes: > Can I just point out that regex is now header only, and thus the dependency > is only there if it's actually used, likewise ICU is not required to be > present at build time, but only if boost/regex/icu.hpp is actually used. This implicit "if you don't include the header then you don't need to link the dependency" approach doesn't scale well to cases where Boost is split into individual packages which are managed by a package manager. When the package manager undertakes to provide a Boost library, it should come with all the dependencies that could be needed for any usage scenario, unless certain features are explicitly not enabled (which is essentially what we have done -- not enabled regex by default in a bunch of libraries; I suppose we could have instead not enabled ICU in regex by default).

1 0

Re: [boost] quadmath as distinct library?
by John Maddock 13 Mar '23

13 Mar '23

On 13/03/2023 02:43, Gero Peterhoff via Boost wrote: > Hello, > * problem description > In boost::math::cstdfloat AND boost::multiprecision::float128 > identical functions for __float128 (quadmath) are provided. > > This is unnecessary overhead. I think it would make sense to "pull > out" the quadmath library as a distinct library. I did this once > canonically, but it doesn't work yet because > boost::math::cstdfloat/boost::multiprecision::float128 have to be > adapted for this. This is a prototype where there is still a lot of > work to be done. But the beginning is done. If you mean https://github.com/boostorg/multiprecision/blob/develop/include/boost/multi… then it's a trivially small header, and spinning stuff out into a separate library has a significant maintenance overhead. > > Would it also make sense to "pull out" quaternion and octonion as > distinct libraries? Historically these were separate libraries, and were unmaintained. Moving them under the Boost.Math "umbrella" means that they do at least get minimal maintenance now. Again, splitting stuff out has a non-zero overhead. John.

1 0

Re: [boost] Reducing dependency on Boost.Regex
by John Maddock 13 Mar '23

13 Mar '23

On 13/03/2023 12:00, Boris Kolpackov via Boost wrote: > A quick note on our experience reducing dependency on Boost.Regex > (and thus ICU) in build2 packages for Boost 1.81.0. Can I just point out that regex is now header only, and thus the dependency is only there if it's actually used, likewise ICU is not required to be present at build time, but only if boost/regex/icu.hpp is actually used. [technically, I haven't yet removed the old C++98 code which does have a dependency on ICU, but it will be going very soon]. John.

1 0

Re: [boost] Reducing dependency on Boost.Regex
by Boris Kolpackov 13 Mar '23

13 Mar '23

Andrey Semashev via Boost <boost(a)lists.boost.org> writes: > Boost.Log can be configured to use std::regex or Boost.Xpressive as an > alternative to Boost.Regex. > > https://www.boost.org/doc/libs/1_81_0/libs/log/doc/html/log/installation/co… > > Boost.Regex is the default because it provides the best performance. I'm > not planning to change this. I don't think there would be strong motivation to change this in Log since it's a leaf library (i.e., no other Boost library depends on it). But we can make this configurable in our package if/when there is interest.

1 0

Re: [boost] Reducing dependency on Boost.Regex
by Andrey Semashev 13 Mar '23

13 Mar '23

On 3/13/23 15:00, Boris Kolpackov via Boost wrote: > A quick note on our experience reducing dependency on Boost.Regex > (and thus ICU) in build2 packages for Boost 1.81.0. Now only the > following (leaf) libraries unconditionally depend on Boost.Regex: > > * Boost.Convert > * Boost.DLL > * Boost.Log Boost.Log can be configured to use std::regex or Boost.Xpressive as an alternative to Boost.Regex. https://www.boost.org/doc/libs/1_81_0/libs/log/doc/html/log/installation/co… Boost.Regex is the default because it provides the best performance. I'm not planning to change this.

1 0

Reducing dependency on Boost.Regex
by Boris Kolpackov 13 Mar '23

13 Mar '23

A quick note on our experience reducing dependency on Boost.Regex (and thus ICU) in build2 packages for Boost 1.81.0. Now only the following (leaf) libraries unconditionally depend on Boost.Regex: * Boost.Convert * Boost.DLL * Boost.Log While the following libraries now have an optional (direct or indirect) dependency (follow the link for details on what functionality is now optional and how to enable it): * Boost.Algorithm[1] * Boost.Asio[2] * Boost.Graph[3] * Boost.Iostreams[4] * Boost.Range[5] * Boost.Spirit[6] To achieve this we had to make the following two changes: 1. Make functionality that requires regex optional. This change was made in all the above-mentioned libraries. In all the cases except Boost.Spirit and arguably Boost.Graph, the regex-based functionality was fairly marginal and making it optional feels like a reasonable trade off. 2. Split Boost.Spirit into three logical "components", all optional: classic, v2, and x3. The rationale here is that only the classic component can be reasonably easily made to work without regex. And classic without regex is what's required by Boost.Serialization (we had to deal with Boost.Serialization because it is a dependency of the majority of Boost libraries). We only had to patch Boost.Graph and are working[7] to upstream our changes. Overall, while this required some effort, it's definitely achievable given appropriate tools (mainly support for dependency configuration in the package manager). [1] https://github.com/build2-packaging/boost/blob/master/downstream/libs/algor… [2] https://github.com/build2-packaging/boost/blob/master/downstream/libs/asio/… [3] https://github.com/build2-packaging/boost/blob/master/downstream/libs/graph… [4] https://github.com/build2-packaging/boost/blob/master/downstream/libs/iostr… [5] https://github.com/build2-packaging/boost/blob/master/downstream/libs/range… [6] https://github.com/build2-packaging/boost/blob/master/downstream/libs/spiri… [7] https://github.com/boostorg/graph/issues/326

1 0

Re: [boost] quadmath as distinct library?
by Dominique Devienne 13 Mar '23

13 Mar '23

On Mon, Mar 13, 2023 at 3:48 AM Gero Peterhoff via Boost < boost(a)lists.boost.org> wrote: > Would it also make sense to "pull out" quaternion and octonion as distinct > libraries? There's already a [Boost.QVM][1] library for Quaternions. Are you aware of it? [1]: https://www.boost.org/doc/libs/1_81_0/libs/qvm/doc/html/index.html

1 0

quadmath as distinct library?
by Gero Peterhoff 13 Mar '23

13 Mar '23

Hello, * problem description In boost::math::cstdfloat AND boost::multiprecision::float128 identical functions for __float128 (quadmath) are provided. This is unnecessary overhead. I think it would make sense to "pull out" the quadmath library as a distinct library. I did this once canonically, but it doesn't work yet because boost::math::cstdfloat/boost::multiprecision::float128 have to be adapted for this. This is a prototype where there is still a lot of work to be done. But the beginning is done. Would it also make sense to "pull out" quaternion and octonion as distinct libraries? thx + regards Gero

1 0

Re: [boost] improve <boost/math/constants.hpp>
by John Maddock 11 Mar '23

11 Mar '23

On 10/03/2023 21:12, Gero Peterhoff via Boost wrote: > Hello, > * Problem description > The constants do not work with the C++23 FP types. We will make sure that they will - once a working implementation is *released*. > > * general hint > To prevent (more) warnings it is useful to introduce this macro: > #if defined(__STDCPP_FLOAT128_T__) From past experience, __STDCPP_FLOAT128_T__ is a deeply unreliable indicator. > * question > In constants the namespaces float/double/long_double_constant+detail > are created type dependent (in case the value constexpr can be > requested). If the value cannot be requested constexpr the conversion > is finally done by boost::lexical_cast. > But the implementation is very complex. I have a better one - but I > may have missed things. > If so - which would they be? Off the top of my head I see two main correctness issues: * Your code introduces *double rounding* for float/double (and maybe long double) types, as a result the constants for these types will no longer guarantee last digit accuracy. This is a deal breaker for me. * For multiprecision types with more digits than we can reasonably store in a string your constants will have insufficient accuracy (cached runtime calculation is needed in this case). It's also lacking some "nice to have" features, for example, you have all UDT types going the lexical_cast route, but if the type can be constructed from a builtin type with sufficient precision, then the code is more efficient and constexpr that way. For example with boost::multiprecision::float128. John. > > * My solution (BOOST_MAKE_MATH_CONSTANT) > see constants_more.hpp, advantages: > - works with all FP types > - compatible to the existing implementation CONSTANT<Type>() > - is clear/understandable (comments) > - may need only one additional namespace static_constants (and not 4) > - provides the constants additionally as CONSTANT_v (constexpr) or > static_constants::CONSTANT_v (not constexpr) (if possible) > > What is your opinion? Are there still errors in it? > > It would be even nicer if boost::lexical_cast and/or > boost::math::tools::convert_from_string were constexpr. This would > further simplify the implementation. > > thx + regards > Gero > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] improve <boost/math/constants.hpp>
by Matt Borland 10 Mar '23

10 Mar '23

> On Mar 10, 2023, at 1:11 PM, Gero Peterhoff via Boost <boost(a)lists.boost.org> wrote: > > Hello, > * Problem description > The constants do not work with the C++23 FP types. > > * general hint > To prevent (more) warnings it is useful to introduce this macro: > #if defined(__STDCPP_FLOAT128_T__) > #define BOOST_FLOATMAX_SUFFIX F128 > #elif defined(BOOST_CSTDFLOAT_FLOAT128_NATIVE_TYPE) > #define BOOST_FLOATMAX_SUFFIX Q > #else > #define BOOST_FLOATMAX_SUFFIX L > #endif > > * question > In constants the namespaces float/double/long_double_constant+detail are created type dependent (in case the value constexpr can be requested). If the value cannot be requested constexpr the conversion is finally done by boost::lexical_cast. > But the implementation is very complex. I have a better one - but I may have missed things. > If so - which would they be? > > * My solution (BOOST_MAKE_MATH_CONSTANT) > see constants_more.hpp, advantages: > - works with all FP types > - compatible to the existing implementation CONSTANT<Type>() > - is clear/understandable (comments) > - may need only one additional namespace static_constants (and not 4) > - provides the constants additionally as CONSTANT_v (constexpr) or static_constants::CONSTANT_v (not constexpr) (if possible) > > What is your opinion? Are there still errors in it? > > It would be even nicer if boost::lexical_cast and/or boost::math::tools::convert_from_string were constexpr. This would further simplify the implementation. > > thx + regards > Gero > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > <config_more.hpp><cstdfloat_types_more.hpp><constants_more.hpp><OpenPGP_signature.sig> Gero, As John and I have said before we are aware that C++23 fixed width floating point types will break Boost.Math. We have a type promotion system for built-in types that will fail because we do not have any code paths for those types yet. GCC 13 will be released in the next month or two and then we can throughly test and fix these issues. For the constants lexical_cast is almost never used. If we are operating with arbitrary precision arithmetic typically the types have string/char* constructors, (e.g. GMP, Boost.Multiprecision, etc.) so lexical_cast is not needed. You would also likely end up having to calculate the constant at runtime which we support (see boost/math/constants/calculate_constants.hpp). If you would like you can open a PR with your changes on our GitHub. Without the tests being run it is hard to tell if there are errors outside of the obvious. Matt

2 1

improve <boost/math/constants.hpp>
by Gero Peterhoff 10 Mar '23

10 Mar '23

Hello, * Problem description The constants do not work with the C++23 FP types. * general hint To prevent (more) warnings it is useful to introduce this macro: #if defined(__STDCPP_FLOAT128_T__) #define BOOST_FLOATMAX_SUFFIX F128 #elif defined(BOOST_CSTDFLOAT_FLOAT128_NATIVE_TYPE) #define BOOST_FLOATMAX_SUFFIX Q #else #define BOOST_FLOATMAX_SUFFIX L #endif * question In constants the namespaces float/double/long_double_constant+detail are created type dependent (in case the value constexpr can be requested). If the value cannot be requested constexpr the conversion is finally done by boost::lexical_cast. But the implementation is very complex. I have a better one - but I may have missed things. If so - which would they be? * My solution (BOOST_MAKE_MATH_CONSTANT) see constants_more.hpp, advantages: - works with all FP types - compatible to the existing implementation CONSTANT<Type>() - is clear/understandable (comments) - may need only one additional namespace static_constants (and not 4) - provides the constants additionally as CONSTANT_v (constexpr) or static_constants::CONSTANT_v (not constexpr) (if possible) What is your opinion? Are there still errors in it? It would be even nicer if boost::lexical_cast and/or boost::math::tools::convert_from_string were constexpr. This would further simplify the implementation. thx + regards Gero

1 0

Re: [boost] [release] Boost 1.82.0 Beta 1 Release Candidate 1 is available
by Tom Kent 09 Mar '23

09 Mar '23

On Thu, Mar 9, 2023 at 10:24 AM Marshall Clow via Boost < boost(a)lists.boost.org> wrote: > Available at: < > https://boostorg.jfrog.io/artifactory/main/beta/1.82.0.beta1/source/> > > The SHA256 checksums are as follows: > > 495b2ae2f6970ea1e635f80222d9f6978148496cdd163e87c37cdd6de3b5ccfc > boost_1_82_0_b1_rc1.zip > 0af2a60f76abb4f411b1bd9c1a553f64454d9414990e8cc12f02f3b431e2ac45 > boost_1_82_0_b1_rc1.tar.gz > efe17bea3f0b2c11f34828f37d5777f30eb6fef57af355c6a6664b08a4339999 > boost_1_82_0_b1_rc1.7z > edf4cb9e8e5a14412b91311438478ef6ce12afe2a54714eb2f0632a454c3d8d5 > boost_1_82_0_b1_rc1.tar.bz2 > > As always, the release managers would appreciate it if you download the > candidate of your choice and give building it a try. Please report both > success and failure, and anything else that is noteworthy. > > -- The Release Managers > Looks good on Windows/Visual Studio. toolset arch compile Link Execute msvc-10.0 32 X X X msvc-10.0 64 X X X msvc-11.0 32 X X X msvc-11.0 64 X X X msvc-12.0 32 X X X msvc-12.0 64 X X X msvc-14.0 32 X X X msvc-14.0 64 X X X msvc-14.1 32 X X X msvc-14.1 64 X X X msvc-14.2 32 X X X msvc-14.2 64 X X X msvc-14.3 32 X X X msvc-14.3 64 X X X Compile means that the b2 command completed without errors Link means that visual studio was able to link a sample executable to a library (libboost_thread-vcXXX-mt[-gd]-1_XX.lib) generated Execute means that the linked program executed without errors. Full build logs can be found here: https://gist.github.com/teeks99/ac05a822cffb8dee3390a8751a6dedeb Tom

1 0

Re: [boost] [release] Boost 1.82.0 Beta 1 Release Candidate 1 is available
by Ruben Perez 09 Mar '23

09 Mar '23

Hi all! As you may know, Boost 1.82 is the first to include Boost.MySQL, so it would be really helpful if you can have a look at it and give it a try. Thanks, Ruben.

1 0

[release] Boost 1.82.0 Beta 1 Release Candidate 1 is available
by Marshall Clow 09 Mar '23

09 Mar '23

Available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.82.0.beta1/source/> The SHA256 checksums are as follows: 495b2ae2f6970ea1e635f80222d9f6978148496cdd163e87c37cdd6de3b5ccfc boost_1_82_0_b1_rc1.zip 0af2a60f76abb4f411b1bd9c1a553f64454d9414990e8cc12f02f3b431e2ac45 boost_1_82_0_b1_rc1.tar.gz efe17bea3f0b2c11f34828f37d5777f30eb6fef57af355c6a6664b08a4339999 boost_1_82_0_b1_rc1.7z edf4cb9e8e5a14412b91311438478ef6ce12afe2a54714eb2f0632a454c3d8d5 boost_1_82_0_b1_rc1.tar.bz2 As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release Managers

1 1

Re: [boost] Moving "sub" libraries to their own repositories
by Mateusz Loskot 09 Mar '23

09 Mar '23

On Wed, 8 Mar 2023 at 21:18, Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > On Mar 8, 2023, at 12:07 PM, Glen Fernandes via Boost <boost(a)lists.boost.org> wrote: > > > > We haven't been allowing this for newer libraries, but it would be nice to > > remove it from these few existing cases too. > > > > Ultimately meta/libraries.json in each library repository would have just > > one library entry. > > Boost/numeric is another such library > > % ls $BOOST/libs/numeric > conversion index.html odeint ublas > doc interval sublibs > > % find . -name sublibs > ./spirit/sublibs > ./chrono/sublibs > ./gil/sublibs TBH, I'm not clear what the existence of the sublibs file means for GIL. The sublibs content says: "sub-directories which are libraries" No idea what would those be in GIL. Extensions? The history of gil/sublibs [1] says: "sublibs file telling regression tools that subdirs contain library tests" what confuses me even more as suddenly sublibs mean two things: - directories which are libraries - directories with library tests [1] https://github.com/boostorg/gil/commit/091c86d884395571cc4a2aa4c149f9f8f184… Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[Release] Master branch is closed for beta
by Marshall Clow 09 Mar '23

09 Mar '23

Master is closed for all changes. See the release schedule at: https://www.boost.org/development/index.html <https://www.boost.org/development/index.html> -- Release managers

1 0

Re: [boost] Moving "sub" libraries to their own repositories
by Vinnie Falco 09 Mar '23

09 Mar '23

On Wed, Mar 8, 2023 at 2:54 PM Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > I suppose, they should be reviewed bottom-to-top. I think you're saying to review them in this order: 1. buffers 2. http_proto 3. http_io ? Thanks

2 1

Re: [boost] Moving "sub" libraries to their own repositories
by Andrey Semashev 08 Mar '23

08 Mar '23

On 3/9/23 00:33, Vinnie Falco via Boost wrote: > On Wed, Mar 8, 2023 at 12:55 PM Glen Fernandes <glen.fernandes(a)gmail.com> wrote: >> If they're separate libraries, they should be reviewed individually >> (and serially, since we never have reviews in parallel). I don't see >> why our review process can't handle that. > > http_proto depends on buffers > http_io depends on http_proto > > What if buffers and http_io get accepted but http_proto does not? lol... I suppose, they should be reviewed bottom-to-top.

1 0

Re: [boost] Moving "sub" libraries to their own repositories
by Vinnie Falco 08 Mar '23

08 Mar '23

On Wed, Mar 8, 2023 at 12:21 PM Glen Fernandes via Boost <boost(a)lists.boost.org> wrote: > In general I favor more fine grained smaller libraries, > than more coarse grained bigger ones. I prefer this as well and I have three libraries in development now which form a logical whole: buffers http_io http_proto These would each have to pass individual review and I suspect that our review process has not been vetted for the model where a larger work is proposed as several individual libraries. Thanks

2 2

Re: [boost] Moving "sub" libraries to their own repositories
by Vinnie Falco 08 Mar '23

08 Mar '23

On Wed, Mar 8, 2023 at 12:17 PM Andrey Semashev via Boost <boost(a)lists.boost.org> wrote: > Why not just merge them all into Functional? Their headers are already > merged, only docs and tests need to be merged. If we do that, then these four libraries will appear as just one library on the various libraries pages: https://www.boost.org/doc/libs/ https://www.boost.org/doc/libs/1_81_0/libs/libraries.htm Each library has slightly different metadata such as the first release date and the author. We would lose these distinctions. Thanks

1 0

Re: [boost] Moving "sub" libraries to their own repositories
by René Ferdinand Rivera Morell 08 Mar '23

08 Mar '23

On Wed, Mar 8, 2023 at 2:18 PM Marshall Clow via Boost <boost(a)lists.boost.org> wrote: > > On Mar 8, 2023, at 12:07 PM, Glen Fernandes via Boost <boost(a)lists.boost.org> wrote: > > > > We have (very) few cases where within a repository we have more than one > > library inside a repository. One example is boostorg/functional whose > > meta/libraries.json has: > > > > - functional > > - functional/factory > > - functional/forward > > - functional/overloaded_function > > > > See: https://github.com/boostorg/functional/blob/master/meta/libraries.json > > > > What do we think about having separate repositories for the last three > > above? e.g. The second one would be boostorg/functional_factory > > > > Some might be better collapsed into the first library (i.e. become part of > > just "functional"). > > > > We haven't been allowing this for newer libraries, but it would be nice to > > remove it from these few existing cases too. > > > > Ultimately meta/libraries.json in each library repository would have just > > one library entry. > > Boost/numeric is another such library > > % ls $BOOST/libs/numeric > conversion index.html odeint ublas > doc interval sublibs > > % find . -name sublibs > ./spirit/sublibs > ./chrono/sublibs > ./gil/sublibs > ./algorithm/sublibs > ./numeric/sublibs > ./geometry/sublibs > ./functional/sublibs > ./utility/sublibs AFAIK, except for numerics, all those sublibs are only there to appease the result matrix to show tests in subpaths. For numerics.. The work I'm doing to get modular arrangement will require that we have a flat structure in libs anyway :-) -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

1 0

Re: [boost] Moving "sub" libraries to their own repositories
by Glen Fernandes 08 Mar '23

08 Mar '23

On Wed, Mar 8, 2023 at 3:17 PM Andrey Semashev wrote: > On 3/8/23 23:07, Glen Fernandes via Boost wrote: > > We have (very) few cases where within a repository we have more than one > > library inside a repository. One example is boostorg/functional whose > > meta/libraries.json has: > > > > - functional > > - functional/factory > > - functional/forward > > - functional/overloaded_function > > > > See: > https://github.com/boostorg/functional/blob/master/meta/libraries.json > > > > What do we think about having separate repositories for the last three > > above? e.g. The second one would be boostorg/functional_factory > > > > Some might be better collapsed into the first library (i.e. become part > of > > just "functional"). > > > > We haven't been allowing this for newer libraries, but it would be nice > to > > remove it from these few existing cases too. > > > > Ultimately meta/libraries.json in each library repository would have just > > one library entry. > > Why not just merge them all into Functional? Their headers are already > merged, only docs and tests need to be merged. > That option is on the table too. Some of them have much fewer dependencies, so there's some appeal in them being separate. In general I favor more fine grained smaller libraries, than more coarse grained bigger ones. Glen

1 0

Re: [boost] Moving "sub" libraries to their own repositories
by Marshall Clow 08 Mar '23

08 Mar '23

On Mar 8, 2023, at 12:07 PM, Glen Fernandes via Boost <boost(a)lists.boost.org> wrote: > > We have (very) few cases where within a repository we have more than one > library inside a repository. One example is boostorg/functional whose > meta/libraries.json has: > > - functional > - functional/factory > - functional/forward > - functional/overloaded_function > > See: https://github.com/boostorg/functional/blob/master/meta/libraries.json > > What do we think about having separate repositories for the last three > above? e.g. The second one would be boostorg/functional_factory > > Some might be better collapsed into the first library (i.e. become part of > just "functional"). > > We haven't been allowing this for newer libraries, but it would be nice to > remove it from these few existing cases too. > > Ultimately meta/libraries.json in each library repository would have just > one library entry. Boost/numeric is another such library % ls $BOOST/libs/numeric conversion index.html odeint ublas doc interval sublibs % find . -name sublibs ./spirit/sublibs ./chrono/sublibs ./gil/sublibs ./algorithm/sublibs ./numeric/sublibs ./geometry/sublibs ./functional/sublibs ./utility/sublibs — Marshall

1 0

Re: [boost] Moving "sub" libraries to their own repositories
by Andrey Semashev 08 Mar '23

08 Mar '23

On 3/8/23 23:07, Glen Fernandes via Boost wrote: > We have (very) few cases where within a repository we have more than one > library inside a repository. One example is boostorg/functional whose > meta/libraries.json has: > > - functional > - functional/factory > - functional/forward > - functional/overloaded_function > > See: https://github.com/boostorg/functional/blob/master/meta/libraries.json > > What do we think about having separate repositories for the last three > above? e.g. The second one would be boostorg/functional_factory > > Some might be better collapsed into the first library (i.e. become part of > just "functional"). > > We haven't been allowing this for newer libraries, but it would be nice to > remove it from these few existing cases too. > > Ultimately meta/libraries.json in each library repository would have just > one library entry. Why not just merge them all into Functional? Their headers are already merged, only docs and tests need to be merged.

1 0

Moving "sub" libraries to their own repositories
by Glen Fernandes 08 Mar '23

08 Mar '23

We have (very) few cases where within a repository we have more than one library inside a repository. One example is boostorg/functional whose meta/libraries.json has: - functional - functional/factory - functional/forward - functional/overloaded_function See: https://github.com/boostorg/functional/blob/master/meta/libraries.json What do we think about having separate repositories for the last three above? e.g. The second one would be boostorg/functional_factory Some might be better collapsed into the first library (i.e. become part of just "functional"). We haven't been allowing this for newer libraries, but it would be nice to remove it from these few existing cases too. Ultimately meta/libraries.json in each library repository would have just one library entry. Glen

1 0

Re: [boost] improve <boost/config.hpp>
by Jeff Garland 08 Mar '23

08 Mar '23

On Tue, Mar 7, 2023 at 11:11 AM John Maddock via Boost < boost(a)lists.boost.org> wrote: > > > Not every compiler defines these macros. Let alone, not every compiler > > properly implements what it advertises. > I think it depends on the compiler - the current crop of the latest are > pretty good at getting these right. > > Also, library-defined macros are worthless as they only allow one to > > know the feature is/isn't supported after including the header, i.e. > > after the fact. C++20 <version> fixes this, but C++20 is a too high > > minimum bar to target. > Sort of, you know that Boost.Config uses <version> wherever possible > already? It does so even in non-C++20 mode since the header is just a > bunch of #defines and is perfectly usable back to C++98 if it exists. > > > > So no, feature macros do not replace Boost.Config. In fact, I'd prefer > > to continue using Boost.Config in new libraries. > > There are still plenty of things Boost.Config is good for: particularly > where getting the configuration correct is tricky - for example if you > want to use <header> then you need to know both that it exists via > __has_include, but also that the current language standard is sufficient > to parse the header, and that it has been been fully implemented. > > On the other hand, for the suggested BOOST_NO_CXX20_CONSTEXPR, > Boost.Config would implement this trivially as (__cpp_constexpr < > 201907L) which is a less obvious win - except perhaps to save folks > having to look up the value - which now I come to think about it, might > be a win after all given that it's value is not 202002L ;) > To me, cppreference is only a click away so I'm unmoved by the 'value being unexpected'. I do appreciate that boost.config can compose for the more complex cases and is tested to ensure portability. Really my main thinking here is a minimization of inter-boost dependency (for the aforementioned stand alone capability). Config is hardly a heavy dependency in the end so if it's useful it can be pulled in by the cmake, but if there's an easy way to check without it then that I think should be the first choice. If it's really the case that the macro coverage in implementations is as spotty as some are implicating here -- then by all means use config -- I'm just thinking I won't really need it going forward. Jeff

1 0

Re: [boost] improve <boost/config.hpp>
by Jeff Garland 08 Mar '23

08 Mar '23

On Tue, Mar 7, 2023 at 11:14 AM John Maddock via Boost < boost(a)lists.boost.org> wrote: > > > Please see: https://en.cppreference.com/w/cpp/feature_test for language > > level macros -- look for _cpp_constexpr. I believe you'll discover that > > every combination you're looking for going back to cxx 2011 is > represented > > -- basically making a boost config macro extraneous. The standard copied > > this idea from boost.config btw and it's quite powerful for portable > > libraries. Note that I regret using the boost.config macro for date-time > > constexpr stuff, because at this point I'd like to make the library > > available in a stand-alone fashion like boost.math. Not depending on > > boost.config would be helpful in that endeavor. > > I think that would be fairly trivial Jeff: I see nothing in date_time > that requires something beyond C++11, so you could probably just check > for Boost.Config's presence with __has_include and only include it when > available. Otherwise assume a conforming C++11 compiler in standalone > mode. > > Thanks John. date-time is currently compatible back to 1998 currently. The constexpr macros from config allow that to happen by removing constexpr when less than c++14 (the limitations of c++11 constexpr were too much to practically support it). But yeah, I agree requiring 14 (and maybe 17 for from_chars support) or above should make standalone date-time relatively easy. I'd actually just like to remove as much of the macro hackery once and for all. Jeff

1 0

Re: [boost] boost.asem seeking endorsement
by Christopher Kohlhoff 08 Mar '23

08 Mar '23

On Wed, Mar 8, 2023, at 2:28 AM, Klemens Morgenstern via Boost wrote: > Channels - which are Experimental. Channels do indeed cover the use cases represented by an asynchronous "condition variable" and "semaphore", and much more besides. A "condition variable" is an unbuffered channel, a "semaphore" is a channel with buffer size N, and a "mutex' is a channel with buffer size 1. IMHO "experimental" is not a reason to avoid using channels if you have these use cases. "Experimental" is just an in-your-face warning that I don't guarantee the same level of API and behavioural stability as other parts of the library. Even so, I don't make breaking changes to their interface lightly. Eventually they will migrate into the main asio namespace. Where channels *have* been limited is that they have required C++17 or later. However, from boost 1.82 they will work with C++11 and up (albeit with some limitations on functionality, but enough to cover the aforementioned use cases). I may also consider in the future adding some algorithms over channels, to encapsulate some common usage patterns that are identified (e.g. using an RAII approach to pair sends and receives). > He also said he's thinking about adding something akin to my mutex. Yes, and my current view is that an asynchronous "mutex" does not add sufficient value over just using a channel either. On the other hand, an asynchronous readers/writers lock (aka rwlock), is something I do see a lot of additional value in, due to the complexity involved in implementing it and particularly if it is upgradeable. I have been considering adding something along those lines in a future release. Cheers, Chris

1 0

Re: [boost] improve <boost/config.hpp>
by Daniela Engert 07 Mar '23

07 Mar '23

Am 07.03.2023 um 19:43 schrieb Peter Dimov via Boost: > Daniela Engert wrote: >> Am 07.03.2023 um 19:19 schrieb Andrey Semashev via Boost: >>> On 3/7/23 21:11, John Maddock via Boost wrote: >>>>> Not every compiler defines these macros. Let alone, not every >>>>> compiler properly implements what it advertises. >>>> I think it depends on the compiler - the current crop of the latest >>>> are pretty good at getting these right. >>> Have MSVC started defining these macros yet? >> I see them in VS2017, but I don't know how complete they are. > This complete: > > https://www.boost.org/development/tests/develop/developer/output/teeks99-09… > Cool, thanks Peter! BTW, this is the reason why we build (and use) Boost with our own build flags to enforce and announce maximum possible language conformance in msvc. The list reveals that the tests are done with non-conformance compiler settings that cater to old customers. -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5

2 1

Re: [boost] improve <boost/config.hpp>
by Peter Dimov 07 Mar '23

07 Mar '23

Daniela Engert wrote: > Am 07.03.2023 um 19:19 schrieb Andrey Semashev via Boost: > > On 3/7/23 21:11, John Maddock via Boost wrote: > >>> Not every compiler defines these macros. Let alone, not every > >>> compiler properly implements what it advertises. > >> I think it depends on the compiler - the current crop of the latest > >> are pretty good at getting these right. > > Have MSVC started defining these macros yet? > > I see them in VS2017, but I don't know how complete they are. This complete: https://www.boost.org/development/tests/develop/developer/output/teeks99-09…

1 0

Re: [boost] improve <boost/config.hpp>
by Daniela Engert 07 Mar '23

07 Mar '23

Am 07.03.2023 um 19:19 schrieb Andrey Semashev via Boost: > On 3/7/23 21:11, John Maddock via Boost wrote: >>> Not every compiler defines these macros. Let alone, not every compiler >>> properly implements what it advertises. >> I think it depends on the compiler - the current crop of the latest are >> pretty good at getting these right. > Have MSVC started defining these macros yet? I see them in VS2017, but I don't know how complete they are. With C++20, the existence of feature test macros and header <version> became mandatory, so both the compiler and the library related macros are there in VS2019 and VS2022. Thanks Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5

1 0

Re: [boost] boost.asem seeking endorsement
by Alan de Freitas 07 Mar '23

07 Mar '23

I'd like to endorse boost.asem. Em ter., 7 de mar. de 2023 às 02:05, Klemens Morgenstern via Boost < boost(a)lists.boost.org> escreveu: > Heya Boost Community, > > I am seeking endorsement for my boost.asem library. > > It provides the following asio-based synchronization primitives: > > - barrier > - condition_variable > - mutex > - semaphore > > Asio currently has timers & (experimental) channels that can help. > However, I think there is a need for more purpose-made utilities to help > more complex asio-based libraries (requests, redis, mysql et al.) > > Code: https://github.com/klemens-morgenstern/asem > Docs: https://klemens.dev/asem/ > > I'm also not too happy with the name, but so far I only came up with an > acronym: Semaphore, Condition_variable, And Mutex. Suggestions are welcome. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > -- Alan Freitas https://alandefreitas.github.io/alandefreitas/ <https://github.com/alandefreitas>

1 0

Re: [boost] improve <boost/config.hpp>
by Peter Dimov 07 Mar '23

07 Mar '23

John Maddock wrote: > > Please see: https://en.cppreference.com/w/cpp/feature_test for > > language level macros -- look for _cpp_constexpr. I believe you'll > > discover that every combination you're looking for going back to cxx > > 2011 is represented > > -- basically making a boost config macro extraneous. The standard > > copied this idea from boost.config btw and it's quite powerful for > > portable libraries. Note that I regret using the boost.config macro > > for date-time constexpr stuff, because at this point I'd like to make > > the library available in a stand-alone fashion like boost.math. Not > > depending on boost.config would be helpful in that endeavor. > > I think that would be fairly trivial Jeff: I see nothing in date_time that requires > something beyond C++11, so you could probably just check for Boost.Config's > presence with __has_include and only include it when available. Otherwise > assume a conforming C++11 compiler in standalone mode. Or just require C++11 and do nothing at all.

1 0

Re: [boost] improve <boost/config.hpp>
by Andrey Semashev 07 Mar '23

07 Mar '23

On 3/7/23 21:11, John Maddock via Boost wrote: > >> Not every compiler defines these macros. Let alone, not every compiler >> properly implements what it advertises. > I think it depends on the compiler - the current crop of the latest are > pretty good at getting these right. Have MSVC started defining these macros yet? >> Also, library-defined macros are worthless as they only allow one to >> know the feature is/isn't supported after including the header, i.e. >> after the fact. C++20 <version> fixes this, but C++20 is a too high >> minimum bar to target. > Sort of, you know that Boost.Config uses <version> wherever possible > already? It does so even in non-C++20 mode since the header is just a > bunch of #defines and is perfectly usable back to C++98 if it exists. Using <version> inside Boost.Config is fine, as long as Boost.Config knows when it can be used and trusted. That's just an implementation detail of Boost.Config. >> So no, feature macros do not replace Boost.Config. In fact, I'd prefer >> to continue using Boost.Config in new libraries. > > There are still plenty of things Boost.Config is good for: particularly > where getting the configuration correct is tricky - for example if you > want to use <header> then you need to know both that it exists via > __has_include, but also that the current language standard is sufficient > to parse the header, and that it has been been fully implemented. > > On the other hand, for the suggested BOOST_NO_CXX20_CONSTEXPR, > Boost.Config would implement this trivially as (__cpp_constexpr < > 201907L) which is a less obvious win - except perhaps to save folks > having to look up the value - which now I come to think about it, might > be a win after all given that it's value is not 202002L ;) BOOST_NO_CXX20_CONSTEXPR would be useful in case of compiler bugs.

1 0

Re: [boost] improve <boost/config.hpp>
by John Maddock 07 Mar '23

07 Mar '23

> Please see: https://en.cppreference.com/w/cpp/feature_test for language > level macros -- look for _cpp_constexpr. I believe you'll discover that > every combination you're looking for going back to cxx 2011 is represented > -- basically making a boost config macro extraneous. The standard copied > this idea from boost.config btw and it's quite powerful for portable > libraries. Note that I regret using the boost.config macro for date-time > constexpr stuff, because at this point I'd like to make the library > available in a stand-alone fashion like boost.math. Not depending on > boost.config would be helpful in that endeavor. I think that would be fairly trivial Jeff: I see nothing in date_time that requires something beyond C++11, so you could probably just check for Boost.Config's presence with __has_include and only include it when available. Otherwise assume a conforming C++11 compiler in standalone mode. John.

1 0

Re: [boost] improve <boost/config.hpp>
by John Maddock 07 Mar '23

07 Mar '23

> Not every compiler defines these macros. Let alone, not every compiler > properly implements what it advertises. I think it depends on the compiler - the current crop of the latest are pretty good at getting these right. > Also, library-defined macros are worthless as they only allow one to > know the feature is/isn't supported after including the header, i.e. > after the fact. C++20 <version> fixes this, but C++20 is a too high > minimum bar to target. Sort of, you know that Boost.Config uses <version> wherever possible already? It does so even in non-C++20 mode since the header is just a bunch of #defines and is perfectly usable back to C++98 if it exists. > > So no, feature macros do not replace Boost.Config. In fact, I'd prefer > to continue using Boost.Config in new libraries. There are still plenty of things Boost.Config is good for: particularly where getting the configuration correct is tricky - for example if you want to use <header> then you need to know both that it exists via __has_include, but also that the current language standard is sufficient to parse the header, and that it has been been fully implemented. On the other hand, for the suggested BOOST_NO_CXX20_CONSTEXPR, Boost.Config would implement this trivially as (__cpp_constexpr < 201907L) which is a less obvious win - except perhaps to save folks having to look up the value - which now I come to think about it, might be a win after all given that it's value is not 202002L ;) John.

1 0

Reminder: Master branch is closing for the beta release TOMORROW
by Marshall Clow 07 Mar '23

07 Mar '23

Calendar is here: https://www.boost.org/development/ <https://www.boost.org/development/> — Your friendly release managers

1 0

Re: [boost] boost.asem seeking endorsement
by Vinícius dos Santos Oliveira 07 Mar '23

07 Mar '23

Em ter., 7 de mar. de 2023 às 02:05, Klemens Morgenstern via Boost < boost(a)lists.boost.org> escreveu: > Heya Boost Community, > > I am seeking endorsement for my boost.asem library. > > It provides the following asio-based synchronization primitives: > > - barrier > - condition_variable > - mutex > - semaphore > I implemented this in the past: https://vinipsmaker.github.io/iofiber/ Point is: I don't care *who* implements it (I wasn't the first and you aren't going to be the last). Boost.Asio *does* need these primitives. You have my endorsement. However don't expect me to go easy on the review. I do want a high quality design. Do you have fiber-local-storage and Boost.Context integration already (this is fiber vocabulary after all, so it would be weird to not offer the fiber as well)? -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

1 0

Re: [boost] improve <boost/config.hpp>
by Andrey Semashev 07 Mar '23

07 Mar '23

On 3/7/23 18:22, Jeff Garland via Boost wrote: > On Fri, Mar 3, 2023 at 8:04 AM Alexander Grund via Boost < > boost(a)lists.boost.org> wrote: > >> >>> But I don't understand why you are against it. After all, there is >>> BOOST_CXX14_CONSTEXPR (BOOST_CXX17/20_CONSTEXPR are still missing - >>> but I already offered that). So we have an expressive scheme >>> BOOST_CXXnn_CONSTEXPR that is unambiguous and readable. >> >> C++14 lifted some major constraints on what can be in a constexpr >> function compared to C++11. Most notably support for more than just a >> return statement. Being able to differentiate that is useful in practice. >> >> > For example, std::round in C++23 is constexpr >> >> The CXXyy part in the Boost.Config macros refers to the language level >> support. While std::round is at library level. So a compiler supporting >> C++14 constexpr syntax might not have a std library where std::round is >> constexpr even if it claims C++23 support. So the better way here would >> be a more focused macro combining the language level of the constexpr >> feature and the library support of what that specific function is using. >> >> Hence a possible BOOST_CXX23_CONSTEXPR is misleading: It doesn't refer >> to the language level anymore. And if you bind that to availability of >> constexpr std::round the next user may want to use it with another std:: >> function which is supposed to be constexpr in C++23 but due to a std >> library defect is not yet. Hence the distinction between library level >> and language level feature macros. >> > > Please see: https://en.cppreference.com/w/cpp/feature_test for language > level macros -- look for _cpp_constexpr. I believe you'll discover that > every combination you're looking for going back to cxx 2011 is represented > -- basically making a boost config macro extraneous. Not every compiler defines these macros. Let alone, not every compiler properly implements what it advertises. Also, library-defined macros are worthless as they only allow one to know the feature is/isn't supported after including the header, i.e. after the fact. C++20 <version> fixes this, but C++20 is a too high minimum bar to target. So no, feature macros do not replace Boost.Config. In fact, I'd prefer to continue using Boost.Config in new libraries.

1 0

Re: [boost] boost.asem seeking endorsement
by Klemens Morgenstern 07 Mar '23

07 Mar '23

Channels - which are Experimental. He also said he's thinking about adding something akin to my mutex. Furthermore you can use a timer like a condition_variable with a bit of wrapper code (cancel becomes notify). None of this seems great to me. On Tue, Mar 7, 2023, 23:21 Peter Dimov via Boost <boost(a)lists.boost.org> wrote: > Klemens Morgenstern wrote: > > I would like them to be in asio, > > but I am not the asio author. > > > > Chris did not seem interested in the idea. > > What did Chris suggest people need to use instead > of this library when they have the problems it solves? > > > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Re: [boost] improve <boost/config.hpp>
by Jeff Garland 07 Mar '23

07 Mar '23

On Fri, Mar 3, 2023 at 8:04 AM Alexander Grund via Boost < boost(a)lists.boost.org> wrote: > > > But I don't understand why you are against it. After all, there is > > BOOST_CXX14_CONSTEXPR (BOOST_CXX17/20_CONSTEXPR are still missing - > > but I already offered that). So we have an expressive scheme > > BOOST_CXXnn_CONSTEXPR that is unambiguous and readable. > > C++14 lifted some major constraints on what can be in a constexpr > function compared to C++11. Most notably support for more than just a > return statement. Being able to differentiate that is useful in practice. > > > For example, std::round in C++23 is constexpr > > The CXXyy part in the Boost.Config macros refers to the language level > support. While std::round is at library level. So a compiler supporting > C++14 constexpr syntax might not have a std library where std::round is > constexpr even if it claims C++23 support. So the better way here would > be a more focused macro combining the language level of the constexpr > feature and the library support of what that specific function is using. > > Hence a possible BOOST_CXX23_CONSTEXPR is misleading: It doesn't refer > to the language level anymore. And if you bind that to availability of > constexpr std::round the next user may want to use it with another std:: > function which is supposed to be constexpr in C++23 but due to a std > library defect is not yet. Hence the distinction between library level > and language level feature macros. > Please see: https://en.cppreference.com/w/cpp/feature_test for language level macros -- look for _cpp_constexpr. I believe you'll discover that every combination you're looking for going back to cxx 2011 is represented -- basically making a boost config macro extraneous. The standard copied this idea from boost.config btw and it's quite powerful for portable libraries. Note that I regret using the boost.config macro for date-time constexpr stuff, because at this point I'd like to make the library available in a stand-alone fashion like boost.math. Not depending on boost.config would be helpful in that endeavor. > However IIRC some C++ standard added support of (temporary) allocations > in constexpr functions. That would be worth a dedicated feature macro as > that change fits the idea described above. > w.r.t. non-standard allocation support, sure that would be an extension perhaps worthy of a boost macro, but also maybe just check the compiler locally in the library that wants to use that extension. Jeff

1 0