- Boost - lists.preview.boost.org

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

Re: [boost] boost.asem seeking endorsement
by Peter Dimov 07 Mar '23

07 Mar '23

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?

1 0

Re: [boost] boost.asem seeking endorsement
by Marcelo Zimbres Silva 07 Mar '23

07 Mar '23

On Tue, 7 Mar 2023 at 06:05, Klemens Morgenstern via Boost <boost(a)lists.boost.org> wrote: > > 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. I would also like to endorse this library (although I don't know whether I qualify for endorsing libs or not). Marcelo

1 0

Re: [boost] GSOC director stepping down and replacement
by Niall Douglas 07 Mar '23

07 Mar '23

On 07/03/2023 01:06, Glen Fernandes via Boost wrote: > David Bellot who has run the Boost GSOC program is retiring from the role: > Thank you David, for your service. > > If anyone wants to step forward and become the new GSOC administrator, > Boost can keep the program running. > > David has generously agreed to help mentor his replacement until the > transition is complete. Also my thanks to David. You kept at it far longer than I thought you would when you graciously took over the role from me! It's a lot of work, and thanks for continuing its success. Niall

1 0

Re: [boost] GSOC director stepping down and replacement
by Mateusz Loskot 07 Mar '23

07 Mar '23

On Tue, 7 Mar 2023 at 02:05, Glen Fernandes via Boost <boost(a)lists.boost.org> wrote: > > David Bellot who has run the Boost GSOC program is retiring from the role: > Thank you David, for your service. Thank you David for the years of your service It's been pleasure collaborate with you over several rounds of GSoC. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

Re: [boost] boost.asem seeking endorsement
by Vinnie Falco 07 Mar '23

07 Mar '23

On Mon, Mar 6, 2023 at 11:43 PM Klemens Morgenstern via Boost <boost(a)lists.boost.org> wrote: > I would like them to be in asio, > but I am not the asio author. > > Chris did not seem interested in the idea. Asio is already too large anyway and would be better as a few separate libraries Thanks

1 0

Re: [boost] boost.asem seeking endorsement
by Ruben Perez 07 Mar '23

07 Mar '23

On Tue, 7 Mar 2023 at 06:05, Klemens Morgenstern via Boost <boost(a)lists.boost.org> wrote: > > Heya Boost Community, > > I am seeking endorsement for my boost.asem library. Endorsed. We need this library to do things like pipelining and request throttling in a sane way. I still think the best place for this would be Asio, but if there's not chance to get it in, Boost.Asem is good for me, too. I hereby volunteer as review manager in case you need it. Regards, Ruben.

1 0

Re: [boost] boost.asem seeking endorsement
by Marcelo Zimbres Silva 07 Mar '23

07 Mar '23

Hi, On Tue, 7 Mar 2023 at 08:43, Klemens Morgenstern via Boost <boost(a)lists.boost.org> wrote: > > I would like them to be in asio, > but I am not the asio author. > > Chris did not seem interested in the idea. Can you give more details, he did not express interest by being silent or has he raised design, useability etc. concerns? Or perhaps he is planning to implement them in asio in the future? Regards, Marcelo

1 0

Re: [boost] boost.asem seeking endorsement
by Andrey Semashev 07 Mar '23

07 Mar '23

On 3/7/23 08:04, Klemens Morgenstern via Boost wrote: > > 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. AsioSync?

1 0

Re: [boost] boost.asem seeking endorsement
by jepessen＠wteam.it 07 Mar '23

07 Mar '23

Hi. I've a simple question: those are primitives built around asio, and according to the documentation you say "This library is not meant as the default method of synchronization of asio-based apps, but to be used by library developers.", so there's a reason to create a different library instead that trying to merge them directly into boost::asio? Regards Daniele Lupo -----Original Message----- From: Boost <boost-bounces(a)lists.boost.org> On Behalf Of Klemens Morgenstern via Boost Sent: Tuesday, March 7, 2023 6:13 AM To: boost(a)lists.boost.org Cc: Klemens Morgenstern <klemensdavidmorgenstern(a)gmail.com> Subject: [boost] boost.asem seeking endorsement 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

2 1

boost.asem seeking endorsement
by Klemens Morgenstern 07 Mar '23

07 Mar '23

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.

1 0

GSOC director stepping down and replacement
by Glen Fernandes 07 Mar '23

07 Mar '23

David Bellot who has run the Boost GSOC program is retiring from the role: Thank you David, for your service. If anyone wants to step forward and become the new GSOC administrator, Boost can keep the program running. David has generously agreed to help mentor his replacement until the transition is complete. If this sounds interesting to you, or if you have any questions about what the task entails, please don't hesitate to inquire further. Glen

1 0

Boost 1.82.0 is now closed for major changes
by Marshall Clow 05 Mar '23

05 Mar '23

Next deadline: On 8-Mar-2023 Boost 1.82.0 closes the beta release. Still open for serious problem fixes and docs changes without release manager review. As always, the release calendar is at https://www.boost.org/development/ <https://www.boost.org/development/> - Boost release team

1 0

improve <boost/config.hpp>
by Gero Peterhoff 03 Mar '23

03 Mar '23

Hi, for more compatibility with existing boost-macros/defines I came up with - see attachment. 1) Is that correct in principle? 2) Problem: for BOOST_NO_CXX23_HDR_XXX I use __has_include. However, __has_include is not guaranteed to exist. How about the solution? 3) Did I miss useful things? thx Gero

6 6

Re: [boost] Has testing on msvc been dropped?
by Tom Kent 02 Mar '23

02 Mar '23

On Wed, Mar 1, 2023 at 6:13 AM Tom Kent via Boost <boost(a)lists.boost.org> wrote: > On Mon, Feb 27, 2023 at 6:16 AM Glen Fernandes <glen.fernandes(a)gmail.com> > wrote: > > > On Mon, Feb 27, 2023 at 6:49 AM Daniela Engert wrote: > > > >> I've noticed that e.g. Boost.Log no longer compiles on msvc 19.35 (i.e. > >> VS2022 update 5). Looking at the test matrix to figure out where the > >> problem might lie, I couldn't find any column with the test results of > >> *any* msvc version, lest the current one. Is there a reason for no > >> longer running the tests with msvc compilers? > >> > >> > > I don't believe it's intentional. > > > > Tom, do you know why the MSVC runners aren't reporting any results? > > > > Looks like my windows runner machine has crashed hard, I'm going to try to > resuscitate it. > It was a dead SSD, reinstalled with a brand-new windows OS, should be back up and cycling normally. In the meantime, I kicked off a set of runs on an Azure VM, so there should be stuff up now. Tom

2 1

Has testing on msvc been dropped?
by Daniela Engert 01 Mar '23

01 Mar '23

Hi y'all! I've noticed that e.g. Boost.Log no longer compiles on msvc 19.35 (i.e. VS2022 update 5). Looking at the test matrix to figure out where the problem might lie, I couldn't find any column with the test results of *any* msvc version, lest the current one. Is there a reason for no longer running the tests with msvc compilers? thank, Dani -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5

6 21

Re: [boost] Delivery Status Notification (Failure)
by Andre Marin 26 Feb '23

26 Feb '23

Hi, I'm interested in becoming a maintainer. I'm interested in the following projects: - Algorithm <https://www.boost.org/doc/libs/release/libs/algorithm/> - Python <https://www.boost.org/doc/libs/release/libs/python/> - Stl_interfaces <https://www.boost.org/doc/libs/release/libs/stl_interfaces/> - Type Erasure <https://www.boost.org/doc/libs/release/libs/type_erasure/> I'm trying to email olivas(a)icecube.umd.edu, per the Boost website but it's not going through. I'm looking for some guidance. I've included the previous request and email error in this email. Thank you, *Andre Marin * *m:* (832) 495-3545 *e:* andre(a)alexamarin.com <https://www.linkedin.com/in/andremarin629/> On Sun, Feb 26, 2023 at 11:46 AM Mail Delivery Subsystem < mailer-daemon(a)googlemail.com> wrote: > [image: Error Icon] > Address not found > Your message wasn't delivered to *olivas(a)icecube.umd.edu* because the > address couldn't be found, or is unable to receive mail. > The response from the remote server was: > > 550 5.1.1 <olivas(a)icecube.umd.edu>: Recipient address rejected: User > unknown in local recipient table > > > > ---------- Forwarded message ---------- > From: Andre Marin <andre(a)alexamarin.com> > To: olivas(a)icecube.umd.edu > Cc: > Bcc: > Date: Sun, 26 Feb 2023 11:46:03 -0600 > Subject: Boost Library Official Maintainer Program > Hi, > > I'm interested in becoming a maintainer. I'm interested in the following > projects: > > - Algorithm <https://www.boost.org/doc/libs/release/libs/algorithm/> > - Python <https://www.boost.org/doc/libs/release/libs/python/> > - Stl_interfaces > <https://www.boost.org/doc/libs/release/libs/stl_interfaces/> > - Type Erasure > <https://www.boost.org/doc/libs/release/libs/type_erasure/> > > > I've been limited to C++11 at work and I'm new to library contributions. > I'm not sure if there are more appropriate projects for noobs or areas of > need I couldn't find on the website. > > Thank you, > > *Andre Marin * > *m:* (832) 495-3545 > *e:* andre(a)alexamarin.com > <https://www.linkedin.com/in/andremarin629/> >

2 1

Future of boost::TypeTraits
by Gero Peterhoff 24 Feb '23

24 Feb '23

Hello, with the planned changes of the dependencies of the boost libraries to newer C++-standards, I would like to ask how this is planned for boost::TypeTraits. 1) In my opinion it would make sense to remove all TypeTraits that are already in the standard, and only provide those that do not exist in the standard (yet). Of course, this depends on the planned minimum standard for boost::TypeTraits. 2) If, on the other hand, boost::TypeTraits is to continue to work with C++03 (for which there may be reasons), however, quite a few adjustments must be made (for newer C++-standards) and bugs must be fixed. Examples: a) - no inline-variables are provided for C++17 (if useful), e.g. is_arithmetic_v - no concepts are provided for C++20 (if useful), e.g. arithmetic - that's why I already asked how to do this best without coming into (name)conflicts with existing structures/namespaces/etc. b) bugs - e.g. is_integral does not contain char8_t (if available) Probably my remarks also apply to other libraries, possibly TypeErasure, TypeIndex, TTI ... All this has to be reworked fundamentally and consolidated if necessary. best regards Gero

1 0

Boost Libraries and Dropping C++ Language Support
by Glen Fernandes 24 Feb '23

24 Feb '23

*Boost library authors and maintainers are free to drop support for old C++ standards in their libraries, at any time. * This includes libraries that other Boost libraries depend on. It even includes core libraries like Boost.Core or Boost.Static_Assert. We ask that maintainers do the right thing by all our users (which may include other Boost libraries) by announcing a future breakage *at least two Boost releases in advance*. When that eventual release time arrives, if Boost libraries are broken in older standards modes due to another Boost library dropping support, it will not block the Boost release. This means that we do not need to announce "Boost is dropping C++03" because Boost doesn't "support C++03" now as it is. It means that you, maintainer of Boost.X, should realize that you are free to announce that "Boost.X is dropping C++XY in version 1.Z" as you see fit. Boost in its infancy thrived because its libraries were on the cutting edge. Boost libraries today should similarly not be confined simply because other Boost libraries have chosen to depend on them. Furthermore, as Boost release managers we support authors exercising this freedom, and do not intend to impose any restrictions on what language support they must maintain. We will add a page to the Boost website stating the above formally. -- The release team (Glen Fernandes, Marshall Clow)

8 12

Boost 1.82.0 is now closed for new libraries and breaking changes
by Marshall Clow 23 Feb '23

23 Feb '23

Next deadline: On 1-Mar-2023 Boost 1.82.0 closes for major code changes. Still open for serious problem fixes and docs changes without release manager review. As always, the release calendar is at https://www.boost.org/development/ <https://www.boost.org/development/> - Boost release team

1 0

Fwd: Futex using boost, threads never wakeup
by tsoumplekas_giorgos 23 Feb '23

23 Feb '23

Subject: Futex using boost, threads never wakeup Hello all I posted the following question in stackoverflow https://stackoverflow.com/questions/75538799/futex-using-boost-threads-neve… 0 <https://stackoverflow.com/posts/75538799/timeline> I am studying about futex synchronisation Following up the manual <https://man7.org/linux/man-pages/man2/futex.2.html> , I tried to syncroniaze threads using boost futex However the threads never wake up #include <iostream>#include <atomic>#include <boost/fiber/detail/futex.hpp>#include <thread>#include <vector>#include <chrono>void wait(std::atomic<int> & futexp){ int one = 1; while(std::atomic_compare_exchange_strong(&futexp, &one, 0)) {} std::cout << std::this_thread::get_id() << "," << futexp.load() << std::endl; boost::fibers::detail::futex_wait(&futexp,0); // std::this_thread::sleep_for(std::chrono::milliseconds(5000)); }void fpost(std::atomic<int> & futexp){ int zero = 0; if (std::atomic_compare_exchange_strong(&futexp, &zero, 1)) { boost::fibers::detail::futex_wake(&futexp); } } std::atomic<int> futexp{1};int main() { std::vector<std::thread> vec; for(int i =0 ; i< 5;++i) { vec.emplace_back([]() { wait(futexp); fpost(futexp); }); } Code demo <https://godbolt.org/z/94hMsrW4a> I am using boost 1.66 and gcc 9.1 What goes wrong with this piece of code ?

3 2

Boost 1.82 closing for new libraries and breaking changes on 2023-02-24
by Glen Fernandes 22 Feb '23

22 Feb '23

On 02/24: Release branch will close for new libraries and breaking changes to existing libraries. Will still be open for bug fixes and other routine changes to all libraries without release manager review.

1 0

Dropping C++03 support (again)
by Peter Dimov 21 Feb '23

21 Feb '23

Greetings, I have a novel idea, let's drop C++03 support. The reasons to do that have been explicated already a number of times, e.g. in https://pdimov.github.io/articles/phasing_out_cxx03.html#_ongoing_costs_of_… but in brief: * C++03 is 20 years old. * A number of intra-Boost dependencies can be eliminated by using the standard equivalent of Boost components. This will help Boost to become "more modular". * Variadic templates allow us to remove the uses of Preprocessor and MPL, which are the primary contributor to slow Boost compilation times. * Almost no new C++03 development occurs in Boost at this point, so C++03 users do not need to upgrade their Boost. To that end, I propose the following: Boost release 1.82.0 is announced as the last one with C++03 support. If critical problems are found in it post-release, we will issue 1.82.1, 1.82.2 and so on, as appropriate (as C++03 users will not be able to just upgrade to 1.83.) Boost release 1.83.0 is announced to require C++11 at minimum. This means compilers that have all the C++11 standard headers, and support all the C++11 syntactic constructs and keywords without issuing errors. (E.g. VS2013 doesn't qualify because it doesn't support the `constexpr` or `noexcept` keywords.) This proposal should ultimately be approved and implemented by the Boost release managers; their opinions are particularly appreciated.

28 98

Mustache has been REJECTED from boost.
by Klemens Morgenstern 20 Feb '23

20 Feb '23

First I want to thank Peter for the submission and all reviewers for their participation in the review process. Please note that votes don't just get added up, but that details of every review, especially the time & effort spent on it, will influence how reviews get weighed. This review was close, with 3 REJECT, 4 Conditional ACCEPT and 0 ACCEPT votes. Rene, Jens and Darryl voted to accept on the condition that the documentation shall be improved/completed. Ruben's review had more complex conditions, among them this one: > 1. The partials argument must be typed according to the data structure it requires. Peter's response to this was "I don't see how this is supposed to be accomplished." I don't know what to make of the technical details here, but I don't think I can make something that might be impossible to accomplish a condition for acceptance. Julien & Vinnie voted to REJECT based on the state of the library, which makes me believe they might change their vote in a future review. Dmitry voted to REJECT based on the mustache language itself, and thus was the only one to reject boost.mustache in general. Based on the almost even split between conditional accept & reject and the lack of unconditional accepts, I decided to REJECT the library at this time. I hope Peter will submit an improved & extended version of this library for review in the future.

6 6

macro BOOST_HAS_CONCEPTS not work + namespace for concepts
by Gero Peterhoff 20 Feb '23

20 Feb '23

Hi, 1) the macro BOOST_HAS_CONCEPTS from <boost/config.hpp> (https://www.boost.org/doc/libs/1_81_0/libs/config/doc/html/boost_config/boo…) not work: https://godbolt.org/z/3G8vTrjcf 2) namespace for concepts Would it make sense to introduce a namespace *only* for concepts to avoid naming conflicts with existing classes? boost::concepts would be useful, but this is already used by the concept-check-library. Then would boost::Concepts be a good choice or could boost::concepts still be used? EG namespace boost { template <typename Type> struct my_trait ...; #if !defined(BOOST_NO_CXX17_INLINE_VARIABLES) template <typename Type> inline constexpr bool my_trait_v = my_trait<Type>::value; #endif #if concepts available namespace Concepts { template <typename Type> concept my_concept = my_trait_v<Type>; } // Concepts #endif } // boost thx Gero

4 10

Review of mustache starts today.
by Klemens Morgenstern 19 Feb '23

19 Feb '23

The formal review of the mustache starts today, Sunday the 5th, and ends next week on Tuesday the 14th. The library was developed & submitted by Peter Dimov. Boost.Mustache is an implementation of Mustache templates in C++11. The master branch is frozen during the review and can be found here https://github.com/pdimov/mustache The current documentation can be found here: https://pdimov.github.io/mustache/doc/html/mustache.html Boost.Mustache is an implementation of Mustache templates in C++11. The documentation of Mustache templates is here: https://mustache.github.io/ Review ======== Please explicitly state that you either *accept* or *reject* the inclusion of this library into boost. The accept can be conditional. Also please indicate the time & effort spent on the evaluation and give the reasons for your decision. The review is open to anyone who is prepared to put in the work of evaluating and reviewing the library. Prior experience in contributing to Boost reviews is not a requirement. Some questions to consider: - Does this library bring real benefit to C++ developers for real world use-case? - Do you have an application for this library? - Does the API match with current best practices? - Is the documentation helpful and clear? - Did you try to use it? What problems or surprises did you encounter? - What is your evaluation of the implementation? More information about the Boost Formal Review Process can be found at: http://www.boost.org/community/reviews.html Reviews can also be submitted directly to me. Thank you Peter for submitting yet another boost library & thanks for all the reviews in advance. Building boost.mustache ======================= Here's how to build the library, starting from scratch: 1. Clone Boost from Github: git clone --recurse-submodules https://github.com/boostorg/boost 2. Clone the Mustache library into the Boost tree: cd boost/libs git clone https://github.com/pdimov/mustache cd .. 3. Build b2: ./bootstrap.sh (We assume Linux and g++ from now on. On Windows, it's just `booststrap`.) 4. Generate the header links in the boost/ directory: ./b2 headers 5. Build the Mustache library and its dependencies (e.g. JSON): ./b2 --with-mustache This will place the compiled libraries into the stage/lib directory. It should contain libboost_container.a/.so, libboost_json.a/.so, and liboost_mustache.a/.so. You can now build and run the Mustache examples by using e.g. g++ libs/mustache/example/html.cpp -o html -I . -L stage/lib -lboost_mustache -lboost_json ./html

20 60

boost::math::tools::promote_args not works with C++23 FP-types
by Gero Peterhoff 19 Feb '23

19 Feb '23

Hi, promote_args from <boost/math/tools/promotion.hpp> not works with new/extended C++23 FP-types https://godbolt.org/z/13fq8a3d7 The problem might be the outdated "manual variadic" implementation for C++03. Well, according to the documentation (https://www.boost.org/doc/libs/1_81_0) boost::math requires C++11 anyway; with a switch to C++11 it also works (std::common_type). This issue also affects some implementations in boost::math::policies. PS: We have (at least) 3 different definitions for the *same* boost::float128(_type/_t) type 1) <boost/config.hpp>: boost::float128_type 2) <boost/math/cstdfloat/cstdfloat_types.hpp>/<boost/math/cstdfloat/cstdfloat_cmath.hpp>: BOOST_CSTDFLOAT_FLOAT128_NATIVE_TYPE/float128_t 3) <boost/math/tools/config.hpp>: BOOST_MATH_FLOAT128_TYPE :-( thx Gero

3 2

Mustache review has ended
by Klemens Morgenstern 19 Feb '23

19 Feb '23

The review of Mustache has ended, thanks to everyone who wrote a review! I would also like to thank the review wizards for granting the extension. That really helped to get us more reviews. I'll try to announce the review results soon, but please note that this is another close call that will need some careful consideration.

2 1

Release Notes: Markdown to replace QBK
by Vinnie Falco 18 Feb '23

18 Feb '23

We need to re-render all of this historical release notes, such as: <https://www.boost.org/users/history/version_1_81_0.html> to be in the style of the new website. This is being taken care of, but it will affect the release process as follows: * Each author will edit the release notes for their library using markdown instead of Quickbook format, as a pull request against a file here: <https://github.com/boostorg/website/tree/master/feed/history> The syntax will be GitHub flavored markdown, with a few Boost-specific extensions (for example, to link against an issue in a boostorg repo). Does anyone object or have comments about this? -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

7 21

[mustache review] Period has been extended until the 18th
by Klemens Morgenstern 17 Feb '23

17 Feb '23

Due to the few reviews and the overlap with the WG21 meeting I have successfully petitioned the review wizards to extend the review period until next Saturday, the 18th of february. Please consider writing a boost.mustache review, since only two have been submitted up to now.

2 2

boost.mustache review reminder (ends this saturday)
by Klemens Morgenstern 14 Feb '23

14 Feb '23

This is a reminder that the boost.mustache review is currently going on and will end this saturday. Please consider submitting a review.

1 0

GSoC 2023 ideas proposals
by David Bellot 13 Feb '23

13 Feb '23

Hi everyone, Boost C++ is candidating again this year to be part of the Google Summer of Code 2023. Each year we are honoured to have students and contributors joining us for the summer and being sponsored by Google. Again, this year, I will ask for all the mentors who are interested in ... well... mentoring a student or contributor, to help us and write their ideas in this document: https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code:-2023 It will help our future students to choose, to develop their own proposal and to be part of our Boost journey. Best regards, David

1 0

[mustache] The docs
by Andrzej Krzemienski 09 Feb '23

09 Feb '23

Hi Everyone, I wanted to share my initial thoughts after reading the docs for the proposed Boost.Mustache. If some library docs said "I am implementing JSON", I more-less know what to expect, because JSON is popular, I used it, so one can reliably predict what the library delivers. This is not the case with Mustache. It is the first time I have heard this name. Apparently, it is a less popular thing. Therefore, I would expect some more introduction than just an external link. The linked page also doesn't contain sufficient information but further links. For instance to https://mustache.github.io/mustache.5.html, but this information also doesn't help me find answers to my questions: 1. What is considered an "optional part" of mustache? Boost.Mustache says it only implements the non-optional parts, but docs in mustache(5) do not indicate the optional parts. 2. It is clear to me that the procedure takes a template (with mustaches) and the data to be replaced. But what is the range of the acceptable formats of this data? The examples show that it is JSON, but does it have to be JSON? Boost.Mustache docs say it could be 'described' classes? But is that all? How about Boost.PropertyTree? What does the specification for Mustache say about it? 3. I do not see any specification (neither in Boost.Mustache docc, nor in the linked mustache(5)) for what is the required behavior when I have nested mustashes with the same name, or a JSON file with nested elements of the same name. Or did I miss this description? Regards, &rzej;

5 17

Boost.Buffers: network-agnostic buffer types and algorithms
by Vinnie Falco 07 Feb '23

07 Feb '23

Greetings. I am asking if there is any interest in a Boost.Buffers library, which consists of the following: * ConstBuffer, MutableBuffer concepts * ConstBuffers, MutableBuffers concepts * const_buffer, mutable_buffer types * DynamicBuffer concept * `source` and `sink` abstract interfaces used to define the Source and Sink concepts * metafunctions for checking all type requirements * implementations of common buffers and dynamic buffers: - buffers_pair - array_of_buffers - circular_buffer - dynamic_string_buffer * Algorithms: - buffer_copy - buffer_size The twist is that this library has no dependency on Asio or Boost.Asio (but Asio will still recognize them thanks to some template heroics and a splash of forward declarations). Why am I proposing this? Well, let me tell you some things... I am currently working on these two libraries: Boost.Http.Proto Boost.Http.Io The Proto library implements HTTP/1 to a fuller feature set than Beast and fixes all the design flaws in Beast (but it is completely not API compatible). This library does not do any network I/O, it is expressed purely in terms of buffer concepts (i.e. depends on Boost.Buffer and not Boost.Asio). The Io library depends on Asio and the Proto library to provide the network algorithms which use Asio to implement HTTP/1. This is the equivalent HTTP functionality of what Beast offers today. Websockets is not included but when I am done with Http I will redo websockets with improvements and new features, and similarly they will be developed as two libraries: Boost.Websockets.Proto Boost.Websockets.Io My motivation for splitting libraries this way is as follows: * Each library is smaller and compiles more quickly * CI turnarounds are faster * Separation of concerns The HTTP Protocol library is designed in a way that much of an application's HTTP business logic can be expressed independently of Asio using only the constructs found in Http.Proto. This especially means fewer templates and faster compilation because Http.Proto is designed from the ground up to avoid templates whenever possible. However during the development of Http.Proto I find myself having to reach for the same buffer algorithms and containers that I developed for Beast (such as the circular buffer and the dynamic buffer). So Http.Proto has been steadily growing these things: <https://github.com/CPPAlliance/http_proto/blob/a3a284f06597ad12ca6cc1782beb…> Extract this independent buffer functionality into a separate library Boost.Buffers would bring these benefits: * Again a smaller library, faster compilation * Faster CI turnarounds * Separation of concerns Additionally, algorithms can be expressed in terms of asio-independent buffer types and concepts. For example, Boost.JSON could implement the boost::buffers::sink and boost::buffers::source interfaces which would enable its use in Boost.Http.Proto and Boost.Requests (an upcoming HTTP client library from Klemens), without having to depend on either of those libraries or Asio. Is this style of development of smaller, fine grained libraries that separate concerns something that is desirable for Boost? Glad for any feedback. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

11 29

Interest in cpp-member-accessor?
by Hans Dembinski 07 Feb '23

07 Feb '23

Dear all, Hubert Liberacki wrote this library https://github.com/hliberacki/cpp-member-accessor that uses a loophole in the C++ standard which allows one to access private members and methods in classes in external libraries that are not under the control of the library author. Since the loophole is legal, it works with all major compilers and on all platforms. No special compiler flags required nor illegal macros like #define private public. I think this should be integrated in Boost, is there interest other from myself? Before you say it is evil, consider all the good that can be done with this in responsible hands. You can add serialisation support to classes that you do not control and you can write efficient Python bindings. I have used this library now in three projects. I used it to add serialisation support and to provide memory views of C++ structures in Python (via the Numpy module), both wouldn't have been possible to do or not would not have been efficient without this. It is a single-header library with 85 lines of code, some of which are comments. This seems a bit small for a separate library, but I am not sure where it would fit in. Best regards, Hans

3 4

[ublas][odeint] PR merge questions
by Antony Polukhin 06 Feb '23

06 Feb '23

Hi, 1) What is the status of adding CMakeLists.txt to ublas and odeint libraries? That file are essential for using Boost in big companies. Especially it is crucial for integrating Boost into buld systwms other that b2. I see there is a https://github.com/boostorg/ublas/pull/142 but no actions for a year. Please, just merge it. 2) Please, merge the fix https://github.com/boostorg/ublas/pull/153 3) Please, merge the fix https://github.com/boostorg/ublas/pull/153 There are many other PR waiting for merge. I do realise that the maintainers could be short on time. May be there are some developers that you trust and write permission could be given to them?

1 0

[gsoc] GSoC mentors
by David Bellot 06 Feb '23

06 Feb '23

Hi Boost mentors for GSoC 2023, If you're interested in mentoring for the Google Summer of Code 2023, please contact me now by email and if you haven't done it already, please start writing your ideas and proposals. The links on github are provided below. The GSoC overview page at Boost is : https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code%3A-Overview The ideas page is here too : https://github.com/boostorg/wiki/wiki/Google-Summer-of-Code:-2023 It's the one you should start filling in. The git repository for your future students and contributors is here: https://github.com/BoostGSoC23 Welcome aboard. Best, David

1 0

The C++ Alliance
by Louis Tatta 03 Feb '23

03 Feb '23

Hello, I am writing to update you on the recent activities of The C++ Alliance. Our newest team members include Matt Borland, Ruben Perez. Matt is developing Boost.Charconv, a C++11 library which polyfills the equivalent C++17 functionality, and contributing to the maintenance and improvement of Boost.Math. Ruben is making significant improvements to Boost.MySQL. Our long-running Boost website project continues to progress and will be deployed in beta this year. As some authors and maintainers may have observed, the code coverage services provided by https://codecov.io have been varying greatly in quality in terms of the user experience of viewing the reports, with the experience being typically worse. To mitigate these risks we are researching the development of a new set of HTML, CSS, and JS templates for presenting high quality coverage reports in the original style. In our continuous efforts to improve documentation quality we have contracted HDoc to explore generating Doxygen compatible XML output so that we might move away from Doxygen in favor of HDoc. This tool is focused specifically on C++ and could be a better fit for Boost libraries that currently use Doxygen. Our vision for documentation includes a significant investment in Asciidoc as the choice of markdown. This means rendering Doxygen/HDoc output in Asciidoc and commissioning a great set of stylesheets for Asciidoc to replace the stock sheets. In the longer term we are investigating Antora as a solution for producing documentation that is well integrated into the new website, to offer a better navigation experience, improved accessibility, more features such as C++ syntax highlighting and code snippet interactivity, and others. We are excited to work on these developments, with the hope they will add vitality and enhance Boost. We look forward to sharing more updates with you in the near future. Best regards Louis Tatta CEO The C++ Alliance

3 2

Two Container Hash libraries on the website
by Andrey Semashev 01 Feb '23

01 Feb '23

Hi, For some reason, Container Hash is listed twice on this page: https://www.boost.org/doc/libs/1_81_0/ The two entries seem equivalent except the "C++ Standard Minimum Level" entry.

2 2

Decommissioning Trac (svn.boost.org)
by Glen Fernandes 31 Jan '23

31 Jan '23

We have Trac in read-only mode after we migrated to Git, but we're still paying for the server. Do people still want to preserve any part of the content in some way? The wiki aside, there are old issues, with comments, and some of them have patches attached. Peter had the idea of generating static HTML content from Trac and hosting that on an archive section on boost.org. (I don't know how difficult this is to do). Thoughts? Suggestions? Glen

5 7

Boost TCP socket read/write issues
by Rahul K R 31 Jan '23

31 Jan '23

Hello All, As part of my project activity, I have to create an asynchronous TCP server application using the boost library. I have created a sample application and it's working. But the issue I am facing is the boost::asio::read API takes a long time to read from the TCP socket, almost 5 seconds. I am using boost library version 1.76.0. I have the following queries regarding this, 1. Is there any known issues for boost::asio::read to consume more time? 2. I am doing reading and writing to the same socket from two threads parallelly, Is that possible with the boost? 3. Is the boost lib can perform well if we get too many requests at a time and process parallelly? I am attaching the sample application code herewith. Please let me know your feedback asap. Regards Rahul

2 1

GSoC 2023 (Google Summer of Code)
by David Bellot 31 Jan '23

31 Jan '23

Hi Boost community, the GSoC 2023 organisation application is now open. Boost is again a candidate this year. We're just waiting for the results to see if we're accepted. In the meantime, we are "recruiting" mentors. Some of you already contacted me a few weeks ago, but maybe some others would be interested to join this fascinating journey. Please contact me now, by mailing list or private email if you're interested. Best, David

2 1

Building the proposed Boost.Mustache
by Peter Dimov 30 Jan '23

30 Jan '23

It's been pointed out that the proposed Boost.Mustache https://github.com/pdimov/mustache (whose formal review is upcoming) is relatively hard to evaluate, because the contents of the repository are in a form that is intended for inclusion into a Boost release. Here's how to build the library, starting from scratch: 1. Clone Boost from Github: git clone --recurse-submodules https://github.com/boostorg/boost 2. Clone the Mustache library into the Boost tree: cd boost/libs git clone https://github.com/pdimov/mustache cd .. 3. Build b2: ./bootstrap.sh (We assume Linux and g++ from now on. On Windows, it's just `booststrap`.) 4. Generate the header links in the boost/ directory: ./b2 headers 5. Build the Mustache library and its dependencies (e.g. JSON): ./b2 --with-mustache This will place the compiled libraries into the stage/lib directory. It should contain libboost_container.a/.so, libboost_json.a/.so, and liboost_mustache.a/.so. You can now build and run the Mustache examples by using e.g. g++ libs/mustache/example/html.cpp -o html -I . -L stage/lib -lboost_mustache -lboost_json ./html

1 1

aedis is ACCEPTED into boost with conditions
by Klemens Morgenstern 28 Jan '23

28 Jan '23

Boost.aedis is ACCEPTED with conditions. Accept: 3 ( + 1 late one) Conditional: 1 Reject: 4 All but one rejections asked for changes that were not fundamental to the design, but rather were about particular implementation details or high-level API design issues. Thus I conclude, based on the reviews, that there is no need for another mini-review. This is also based on Marcelo's engagement, so I am confident that many issues will be addressed in the future . These are the conditions - name it boost.redis - clearly document/specify the behaviour of async_exec, async_receive & async_run, how they interact and all the edge cases (and unit test them) - unit tests for error handling, especially for pipes. - add a design discussion & FAQ page. That should mostly copy & paste from the review discussions. - from_bulk & to_bulk should either us tag_invoke or be be renamed to aedis_from_bulk or aedis_to_bulk - remove memory_resource usage and optimize the allocation strategy of a request object (using new/delete), so that it ideally allocates once and then reuses the memory Please note that the inclusion into boost does not mean that it has to be shipped with the next release. I also strongly recommend development of typed commands, possibly with code generation. This is however not a condition and does not need to be in the first release that's included in boost. Another recommendation is to add some very basic explanation of redis, as some users will read your doc before they look into redis. I want to thank everyone who submitted reviews, especially Ruben who really drilled down on some details and brought in his experience from MySQL. Thank you Zach for getting the discussion started on type-safe command access; based on the discussions I am confident that some feature like that will be added on top of the existing APIs. Similarly I want to thank Дмитрий, Sam & Alan, who's review helped me to formulate the conditions. I am also grateful for (who I think are) first time reviewers, Mohammed Nejati, Robert Leahy, Sam Hartsfield & Miguel, and of course our boost veterans Vinnie & Christian. Likewise I want to thank Marcelo for all his responses to reviews and questions and of course for all the work that went into developing aedis. Congratulations Marcelo!

5 6

[Aedis] Formal Review: We could have done better
by Vinnie Falco 26 Jan '23

26 Jan '23

In hindsight, I feel like perhaps we collectively failed the review process. I think that Boost.Aedis was in fact not ready for a review and it did a disservice both to the library and the author that we rushed to review it. Instead, the relevant subject matter experts such as I, Alan de Freitas, Klemens Morgenstern, Reuben Perez, to a lesser extent Christian Mazakas, Mohammed, and a few others should have taken Aedis under our wing and helped to "get it into shape" before the review. Speaking for myself I wish I had put more time into helping the author get the library into the best possible condition. Instead of waiting until the review, I should have helped Marcelo address the flaws ahead of time. For example: <https://github.com/mzimbres/aedis/issues/51> and <https://github.com/mzimbres/aedis/issues/47> The library should not have gone into the review without one or more revisions to the documentation so that common questions that came up during the review were already answered, perhaps in a FAQ section. In particular, reviewers should not have had to ask why async_run or async_exec (see my example exposition in issue 51 above). I also think that the library would have benefited from a concerted effort to get it in the hands of users. I spent a bunch of energy ahead of time to get users for Beast before submitting it for review. It was already deployed in production systems, and there were other projects that started integrating it both open source and closed. We should have at the very least advertised Aedis in places like the redis++ repository (perhaps with a new GitHub issue). Forums, and such. And looked for individual C++ projects already using Redis and informed them of Aedis. For any new libraries we should look at the lesson of Aedis and consider whether or not a similar treatment would result in a better review of the candidate library. Regardless, I have the highest regard for Marcelo as he demonstrates a mastery of Asio and a commitment to quality, even if the library's outcome of the review is not favorable. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

4 6

Fwd: aedis review starts today
by Vinnie Falco 25 Jan '23

25 Jan '23

The following review came in after the review period ended. I am reposting it with permission. A copy was also sent by the reviewer to the review manager. ---------- Forwarded message --------- From: M P <miguelportilla64(a)gmail.com> Date: Wed, Jan 25, 2023 at 11:14 AM Subject: RE: [boost] aedis review starts today To: <klemensdavidmorgenstern(a)gmail.com>, Vinnie Falco <vinnie.falco(a)gmail.com> > Please explicitly state that you either *accept* or *reject* the inclusion of this library into boost. I ACCEPT this library into boost. My only concern is that although Redis may be the flavor of the day, project popularities fade. If Redis is supplanted, I wonder how effective boost maintainers down the road will be to remove it. > Also please indicate the time & effort spent on the evaluation and give the reasons for your decision. > Additionally, stating your knowledge of redis and asio would be helpful for Me. I had no prior knowledge of Redis before reviewing Aedis, but I am familiar with Boost and Asio. Before diving into Aedis, I began by studying Redis, its RESP protocol, and real-world use to help me understand why the Aedis project might be useful to the c++ community. It quickly became apparent that Redis is very popular. It is the most popular database used on Amazon Web Services, the world’s largest cloud service provider. It is also ranked first in its category and the top ten of all categories by DB-Engines. In today’s full-stack web applications, users expect responsiveness, and Redis is an important component in scaling architecture to meet demands. Aedis grants c++ developers Redis access, empowering their software to participate in this evolving sphere of technologies. I spent about three days learning about Redis, RESP3, and Aedis. While evaluating Aedis, I built the project in Linux and Windows and performed tests using Visual Studio 2022. The project examples provide a variety of scenarios that may be useful as starting points for folks with different requirements. > - Does this library bring real benefit to C++ developers for real world use-case? Absolutely. Any c++ project with heavy utilization of Relational Databases can benefit from the cache performance Redis provides. Projects that do use a Relational Database may also be able to use Redis as a mechanism to share data across servers. There are many real-world use cases ranging from web, multi-user games, fintech, and blockchain. > - Do you have an application for this library? I do not have a software application at the moment that uses Redis. I am working on a project that might end up using Redis and if so, would likely use Aedis. > - Does the API match with current best practices? Yes, the API is well-matched with current practices. Aedis is based on Asio and it does a good job of keeping in line with it. > - Is the documentation helpful and clear? The documentation within the sources (Doxygen) is helpful. The project readme.md file can be improved. Having steps to build the project for various operating systems would be nice. Providing cmake examples to generate project solutions for Visual Studio might be a good idea. Eg. cmake -G "Visual Studio 17 2022" -A x64 -B bin64 -DCMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake Although seemingly trivial to some, it helps reduce friction (and frustration) to newcomers and increase adoption. > - Did you try to use it? What problems or surprises did you encounter? Yes, I built the included examples and tested them with a Redis server. It may not be obvious to new users that most functions can throw an exception. Some exception messages should be elaborated. For instance, upon a failure to a server that refused a connection, the exception message was "multiple exceptions". Small nits… May want to consider renaming the function 'healthy_checker' to 'health_check'. Rename the abbreviated response variable 'resp' in the examples to `response`. `resp` can be confusing in this context considering RESP is an acronym for the communication protocol. It might be helpful to use an enumeration (or something else) for request commands. Not only would it provide type safety but it also aids in knowing the commands without having to reference them in the docs. > - What is your evaluation of the implementation? Overall I believe Aedis is well-designed and written, Marcelo has done an excellent job. Unfortunately, this library requires c++ 17 with an emphasis on c++ 20. This likely eliminates a large population of c++ users. Best, Mickey -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

1 0

aedis review period has ended
by Klemens Morgenstern 25 Jan '23

25 Jan '23

The review for aedis has concluded. I will announce the result soon. Thanks to everyone who participated in the review and discussion.

1 0

aedis review starts today
by Klemens Morgenstern 24 Jan '23

24 Jan '23

The formal review of the aedis starts today (15th) and ends next week on Tuesday (24th). The library was developed & submitted by Marcelo. Aedis ================= Aedis is a Redis client library built on top of Boost.Asio that implements the latest version of the Redis communication protocol RESP3. Some of its distinctive features are * A connection class that provides high-level functions to execute Redis commands and receive server pushes concurrently. * Automatic pipelining of commands. * Support for STL containers and serialization of user-defined data types. * Low-latency: Responses can be read in their final data-structure without creating copies. Aedis links Github: https://github.com/mzimbres/aedis Homepage: https://mzimbres.github.io/aedis/ Git tag: v1.4.1 Tarball: https://github.com/mzimbres/aedis/archive/refs/tags/v1.4.1.tar.gz Redis Links: Redis: https://redis.io/ RESP3: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md Pipelines: https://redis.io/docs/manual/pipelining/ Redis commands: https://redis.io/commands/ Local Redis =========== Redis can be also easily installed on your local machine, for example, on Debian run "apt install redis". You might also want to use docker https://www.docker.com/blog/how-to-use-the-redis-docker-official-image/ Redis server for the Boost review ================================= We also have a public aedis server available for testing, please contact me or Marcelo for the details. Review ======== Please explicitly state that you either *accept* or *reject* the inclusion of this library into boost. Also please indicate the time & effort spent on the evaluation and give the reasons for your decision. The review is open to anyone who is prepared to put in the work of evaluating and reviewing the library. Prior experience in contributing to Boost reviews is not a requirement. Some questions to consider: - Does this library bring real benefit to C++ developers for real world use-case? - Do you have an application for this library? - Does the API match with current best practices? - Is the documentation helpful and clear? - Did you try to use it? What problems or surprises did you encounter? - What is your evaluation of the implementation? Additionally, stating your knowledge of redis and asio would be helpful for me. More information about the Boost Formal Review Process can be found at: http://www.boost.org/community/reviews.html Reviews can also be submitted privately to me, and I will not disclose who sent them. I might however cite passages from those reviews in my final decision. Thanks to Marcelo for providing us with a new library & thanks for all the reviews in advance.

13 43

Fwd: Aedis review (Mohammad Nejati)
by Klemens Morgenstern 24 Jan '23

24 Jan '23

---------- Forwarded message --------- From: Mohammad Nejati [Ashtum] <ashtumashtum(a)gmail.com> Date: Tue, Jan 24, 2023 at 7:02 PM Subject: Aedis review (Mohammad Nejati) To: klemensdavidmorgenstern(a)gmail.com <klemensdavidmorgenstern(a)gmail.com> First I want to say thank you to Marcelo for the effort he put into creating such a library and improving the ecosystem around Asio. >Does this library bring real benefit to C++ developers for real world use-case? Yes, Redis is extensively used in server-side services, so having a high-quality asynchronous C++ library is a need for this type of application. >Do you have an application for this library? Yes, I work on backend services and use Redis as a key-value storage and a message broker (Redis streams) and I am in need of an asynchronous Redis library. >Does the API match with current best practices? >Did you try to use it? What problems or surprises did you encounter? Yes, I am a user of Aedis already and have used it in an application too. There are some issues that I have found in the practical usage of this library, some of them are related to the API and some of them have performance implications. The connection being reconnectable seems a design flaw: The idea behind having a reconnectable connection seems to be there to make the user's life easier (by keeping the user's request and retrying them on reconnect) but there are some issues: A network disconnect leaves the user's request in an undefined state (they might have applied on the server or not) we can't simply retry them after a reconnection it requires the user's intervention to handle a reconnect. For example, we can't simply retry an INCRBY command, it might increment the value twice. Because of the possibility of reconnecting the handshake process has to be done by users (by sending HELLO command as the first request) and on a reconnect this should be repeated again, this affected the implementation in a way it has to check for each command to see if it is a HELLO command or not. If a user is using async_receive there is no way to detect a disconnect, users have to use some form of async condition variable (which Asio doesn't have at the moment) to signal the disconnect event. On a reconnect all Redis subscriptions are dropped and again a user has a hard time signaling the async_receive part of the code to subscribe again. Because of the possibility of reconnecting, each request gets a lot of boolean config parameters to handle the reconnect scenario (cancel_on_connection_lost, cancel_if_not_connected, cancel_if_unresponded, hello_with_priority) that made the API difficult to use and understand. So if all these efforts have a limited use case (implicitly retrying the requests that are read-only or do not matter if executed twice) I think a user can handle this scenario with a custom wrapper type would be better instead of making the whole connection reconnectable. There are a lot of rescheduling for reading a single push event (performance issue): At the moment the demultiplexing of Redis events seems to happen with a strategy https://github.com/mzimbres/aedis/blob/master/include/aedis/detail/guarded_… The problem is that for reading each event message around 4 rescheduling on executor happens (it might be less or more than 4 it is hard to be sure from the code) and that has degraded the performance of reading push events (rescheduling on Asio executors is not a cheap operation). There is no possibility of reading push events in batches (performance issue): Redis pub/sub receives its messages as push events and because it is a way of broadcasting messages it is sometimes used at rates like 50,000 messages per second, with the current API there is no possibility for reading these messages in batches which made the reading operation very costly. Creating an Asio timer for each request (performance issue): Currently, Aedis creates an Asio timer for each request in the queue to act as an async condition variable, but it seems it can be eliminated if the exec_op is converted into a polymorphic type which can be resumed externally, after this change would a need for an Asio service too, to destroy paused operation on a service shutdown. >Is the documentation helpful and clear? I find them very clear and well written but it would be nicer to have more examples of real-world usages of Redis, I see documentation links to the example directory for examples. It would be nice if add a couple of them to the document and explain what is going on. There is no example of how we should use this library to work with Redis streams. The echo server benchmark doesn't carry any information and is misleading in my opinion, if there is some benchmark it should be a practical usage example. >Please indicate the time & effort spent on the evaluation and give the reasons for your decision. Because I had some previous experience with this library I think in total it should be around 4 days of debugging and evaluation. >Please explicitly state that you either *accept* or *reject* the inclusion of this library into boost I think this library needs to see more practical usage to find its shape in terms of the quality of implementation and the quality of the provided user interface. There are various modes we can use Redis (key-value storage, message broker, pub/sub) and each one can reveal shortages in the performance or API. At this stage, I think it is too early for inclusion in the boost.

2 1

Aedis review is about to end
by Klemens Morgenstern 24 Jan '23

24 Jan '23

This is a reminder that later today (in about 12h) the review of aedis will conclude. If you intend to submit a review, please do it soon or let me know if you need more time.

1 0

Fwd: Aedis Review
by Klemens Morgenstern 24 Jan '23

24 Jan '23

This review was sent directly to me. ---------- Forwarded message --------- From: Robert A.H. Leahy <rleahy(a)rleahy.ca> Date: Tue, Jan 24, 2023 at 1:04 PM Subject: Aedis Review To: klemensdavidmorgenstern(a)gmail.com <klemensdavidmorgenstern(a)gmail.com> Sending directly as I'm not on the Boost mailing list. *Knowledge of Redis* No more than can be gathered by Wikipedia. *Does this library bring real benefit to C++ developers for real world use-case?* Yes. Having an idiomatic (i.e. Asio-like) way to interact with something in C++ brings real benefit. *Do you have an application for this library?* Not immediately but Redis is in use within my company so I can see one arising in the future. *Does the API match with current best practices?* I share Zach Laine's concerns about raw strings (status quo) vs. a more structured way to pass data to the API. However I'm sympathetic to arguments that: - Redis-like products may extend the set of commands and that's important to support - Redis itself may extend the set of commands and it'd be a shame to force users to wait for a library upgrade (or worse a storm of forks) to get support for new features Additionally I see the request for a more structured way to pass data to the API as a pure extension: What exists right now is a good lower layer that something higher level can be built on top of. It's not one or the other, in a perfect world both would exist. I think the API should be more generic, for example: - Why is std::tuple used rather than supporting anything which supports the tuple protocol? - std::pmr::string is used internally by aedis::request but the documentation suggests that for deserialization purposes only std::string is supported (along with only std::vector et cetera) - Why the concrete reliance on aedis::resp3::request (rather than any type which obeys some protocol)? I don't think that aedis::basic_connection::reset_stream should exist: It marries the class too heavily to TCP-like streams and doesn't add anything beyond being a convenience wrapper for several functions of the underlying stream. If anything it should be a free function. Note that the above concern is mirrored somewhat in several parts of the code where members such as is_open are used. Several opportunities to add noexcept (conditional or otherwise) should be taken. I don't see any reason why detail::connection_base::get_executor shouldn't be noexcept, for example. I feel as though read and write buffers should be customizable rather than being married to std::pmr::string (detail/connection_base.hpp). If the implementation is going to maintain its own buffers I think there should be a way to inspect them for post mortems (e.g. generating clear and context-rich error messages). *Is the documentation helpful and clear?* Yes, although some things could be made clearer. It was unclear to me at first glance what it mean to "[r]eset[] the underlying stream" (documentation for aedis::basic_connection::reset_stream), for example. *Did you try to use it?* I did not. *What is your evaluation of the implementation?* I'd rather see operator[] (possibly combined with an assert) rather than at(). I dislike the AEDIS_CHECK_OP# macros (by virtue of the fact that they're macros and, in my opinion, substantially reduce the readability of the code at the point where they're used). In detail/connection_ops.hpp:271 the operation appears to complete sucessfully because stopping "was requested from the outside." My first instinct is that in this situation the operation should end with operation_canceled. *Please explicitly state that you either accept or reject the inclusion of this library into Boost* Accept. I don't think any of the concerns I've raised are breaking and so they can be addressed later. Thanks, --Robert

1 0

Fwd: aedis review starts today
by Ruben Perez 23 Jan '23

23 Jan '23

Forwarding to the whole ML, I hit the wrong button. Thanks Marcelo for noting it. ---------- Forwarded message --------- From: Ruben Perez <rubenperez038(a)gmail.com> Date: Mon, 23 Jan 2023 at 14:04 Subject: Re: [boost] aedis review starts today To: Marcelo Zimbres Silva <mzimbres(a)gmail.com> Hi Marcelo, I'll try to answer to the several points you made in a single email. > > To fix this properly I would need a tool similar to what protobuff is > to grpc: generate requests and responses stub from a schema. > > Aedis however is not trying to do that, it provides the infrastructure > with which such a tool could be created. Perhaps there is no place in > Boost for such a library, but it is still necessary. I do think there is a place in Boost for a library like this. I don't think we need neither a 100% type-safe solution, nor to completely hide the general runtime interface that request::push() gives us. But I think we do have some usability barrier here, and you need to have a plan on how to evolve it to make it better, before the library gets into Boost and you loose the ability to introduce big breaking changes. I don't think the type-safe solution should span *all* Redis commands, but only the most common ones. If the command the user wants does not have type-safety implemented, she can always use what it's in place now. Simple interfaces for simple uses, complex ones for advanced use cases (that's something I learnt in MySQL the bad way). > > As an example of this, the library's own example cpp20_containers, > > in the hgetall function, uses the type std::map<std::string, > > std::string> for the hgetall response, which will be okay unless the > > key is not set, in which case you will get an error. I think this > > has an enormous potential for causing hidden bugs (and even > > vulnerabilities). I've also noticed that if you mismatch the sizes > > of the pipeline request and response, you get an assertion (so UB). > > To avoid this you can wrap the response type in std::optional, for example > > std::optional<std::map<std::string, std::string>> > > I don't lock users in this behaviour because they might not want it. > Perhaps it is desirable to have an error instead of having to check > whether the optional has a value. The user must know what he needs. Hand't think of that. Although I don't have data to speak, I get the impression that this feature will be used unintentionally more than intentionally. But it might just be an opinion. > As an alternative I could lock-in users on resp3 types: maps, sets, > etc. But then how to represent data structures that have no > corresponding C++ types. It would also be inefficient as it would > require first copying and then converting. That's something I didn't take into account when I wrote the review, and that gets solving this harder. Is there a way, given a type T, to know whether the response to a given command (say "GET") is compatible with T? Without performing the actual parsing? I can think of the following solutions (excuse me if any of these have flaws I haven't taken into account): 1) A runtime checking option. For the most common commands, you provide a set of helper functions like request::push_set or request::push_hgetall(). request remembers which commands have been added. The deserializing function checks for type compatibility before proceeding to the actual deserialization. This would pick the std::optional<T> vs T mismatch. Not sure if it's worth paying the price, though. You could provide an option to disable this at runtime. 2) A compile-time checking option. I envision this as something like typed_request<commands::get, commands::hgetall, ...>. You can check for compatibility at compile-time. You will probably want something like commands::any to provide access to commands that don't have a type-safe interface. Note that I don't think this should replace aedis::request, but complement it. Do you find any of these solutions appealing? Knowing that a strategy is in-place to evolve the library towards type-safety would alleviate many of my concerns. > I am trying to understand how you avoid these risks in Boost.MySql but > it seems it suffers from the same problems? > > I mean this: https://github.com/boostorg/mysql/blob/ac7285c62163c0de40a466ecaeca13f7de5a… > > conn.query("SELECT salary FROM employee WHERE first_name = > 'Underpaid'", result); > double salary = result.rows().at(0).at(0).as_double(); > > The query is not type safe [1] and the result can mismatch the the > query. Why would it be considered ok for Boost.MySql and not > Boost.Aedis? > > Disclaimer: I am not trying to make a case or open a precedent, it is > purely technical. I might be wrong but I would like to clarify anyway. So we have two parts here. The "client -> server" interface has two flavours: connection::query(string_view), and statement::execute(const ParamsTuple&). query() should only be used for queries that don't have parameters provided by the user (I should change that example, BTW). statement::execute takes a tuple of parameters. The client will check for compatibility in terms of number of parameters. Types are not checked in the client because the server is *very* flexible with type conversions. The second part is the "server -> client" interface (mysql::resultset), which is the one I think you're referring to here. It's a purely variant-like interface. Still, there is code to runtime-check that what the server sent matches the query metadata, which is provided by the server. I view this variant-like interface similar to Boost.JSON parsing into a json::value. I'd say the differences I see from the Aedis case are: * There is no way for the MySQL client to know the resulting data structure from a query given the contents of a query. "SELECT product FROM products" can yield 10 different data types, and without the table definition, you can't know. I got the impression this is not the case in Redis - "HGETALL" always returns the same data structure (please correct me if I'm wrong). * From a user perspective, when I use a variant-like interface (like the one in Boost.JSON or in Python database access), my head is set to "type checking is my responsibility". I know I'm in runtime. When I use a compile-time interface, I get much more relaxed. I got the "I'm at compile-time safety" with Aedis, but that impression is not right. Again, this is just based on what I felt while using the library for the first time, other users might feel differently. I think if I had encountered an aedis::value, similar to json::value, I would have switched my mind to "I'm at runtime". I'm not saying this is the solution, I'm just trying to explain myself. * I still got criticism for this in MySQL, and I've got a safer compile-time interface planned (https://github.com/boostorg/mysql/issues/60) The idea is that you define a row type T, so you can then read a typed resultset<T> (or individual rows by calling connection::read_one_row(T&)). My idea is to fully check for type compatibility as soon as I've got the query metadata available - that would be similar to solution 1) I proposed you earlier in this email. * If you're referring to the ability to compose SQL queries in a type-safe way, as sqlpp11 does, I did determine this as out of scope. As SQL is a standard, you usually get this at the database compatibility layer, rather than in individual drivers. I see it as more involved than providing type-safety to Redis commands - please apologies if this statement is not correct. > > This is to make it safe by default and in part because Aedis is > centered around the adapter. In the same sense that you can write an > adapter to receive responses in the data-structure that makes most > sense to the application e.g. std::map, std::unordered_map, > boost::flat_map etc. You can also customize the way errors are > handled. For example, > > * Errors like type mismatch are usually unrecoverable and you might > want to fail fast and let the async_ operation itself fail instead of > proceeding in an unknown state. > > * If you can tolerate errors like that you can write an adapter that > does not communicate an error to the parser. I did not make this the > default because it looks unsafe, people will usually expect > async_exec(req, adapt(resp)) to throw when the response can't be > stored in resp. > > I am perhaps at fault here for not documenting this feature. I thought > however not many people would want this behaviour. I think you're right and that this is the most common case. I had a look at the Python redis driver, and they do the following: * By default, fail the operation if any of the pipeline requests failed. * If you pass a certain config option, individual errors are reported as error response objects. So if you sent [C1, C2, C3] and C2 failed, you will get [C1_response, C2_error_info, C3_response]. I think your default is right. Maybe you could provide the option to report errors individually by having the user provide a) std::tuple<leaf::result<T1>, leaf::result<T2>> Instead of b) std::tuple<T1, T2> If the user did b), then do the same you're currently doing, otherwise report errors individually. I would like to know your thoughts on these two matters (type-safety and error handling), as having a plan would alleviate many of my concerns. Regards, Ruben.

2 1

Regarding password protected file
by Daggumati, Rajesh 23 Jan '23

23 Jan '23

Hi Team, We have a project requirement where we store the logs in .csv file and that .csv file should be password protected. It means that User can enter the password to open the .csv file. do we have any library to create a password to open a .csv file in boost? Please let me know your thoughts on above query. Regards, Rajesh D Confidential - Company Proprietary Please be advised that this email may contain confidential information. If you are not the intended recipient, please notify us by email by replying to the sender and delete this message. The sender disclaims that the content of this email constitutes an offer to enter into, or the acceptance of, any agreement; provided that the foregoing does not invalidate the binding effect of any digital or other electronic reproduction of a manual signature that is included in any attachment.

3 3

boost.aedis ongoing review reminder
by Klemens Morgenstern 20 Jan '23

20 Jan '23

The review period for boost.aedis is half way done, please consider submitting a review!

1 0

Re: [boost] aedis review starts today
by Zach Laine 18 Jan '23

18 Jan '23

As Marcelo pointed out, I did not Reply All; here is the email: On Tue, Jan 17, 2023 at 3:40 PM Zach Laine <whatwasthataddress(a)gmail.com> wrote: > > On Tue, Jan 17, 2023 at 3:11 PM Marcelo Zimbres Silva > <mzimbres(a)gmail.com> wrote: > > > > On Tue, 17 Jan 2023 at 20:39, Zach Laine via Boost > > <boost(a)lists.boost.org> wrote: > > > > > > No. In particular, the API requires the user to write lots of Redis > > > strings by hand. A typo will not be detected until runtime. The > > > set of Redis keywords is fixed; there's no reason not to make an > > > enumeration of them all, like this: > > > > I had enums in the past but I had to remove them for a couple of reasons > > > > 1. There are a multitude of possible commands in the Redis stack, for example > > > > * Redis search: https://redis.io/commands/?group=search > > * Redis graph: https://redis.io/commands/?group=graph > > * Redis time series: https://redis.io/commands/?group=timeseries > > * Redis json: https://redis.io/commands/?group=json > > * Perhaps more I might be missing righ now. > > I don't yet see the problem. In the enumeration I made, there's a > JSON_DEBUG (JSON.DEBUG from https://redis.io/commands/?group=json, but > with s/./_/), etc. None of these enumerators collides with any other; > I compiled the resulting enumeration to check exactly this. Am I > missing something? > > > Then, we would probably agree that the command syntax is equally > > important. To check it properly I would have to write a generator that > > parses the description of each command and generates a checker, see > > https://github.com/redis/redis/tree/unstable/src/commands. > > > > I have made no thoughts so far about how that would work and if I get > > that correctly I would still have to watch for versioning (what > > changes from release to release), what new commands were implemented > > and which were deprecated. > > Yep. That's the job. The good news is that a new version need not be > that disruptive. You only ever need to add to the enumeration, and > you can add a single deprecation-detection function that compares any > enumerator used against the list of enumerators that are deprecated. > > > That might be enough for Redis, but them I would be keeping other > > Redis-like databases off, for example > > > > * https://github.com/Snapchat/KeyDB > > * https://github.com/scylladb/scylladb/blob/master/docs/dev/redis.md > > * https://github.com/dragonflydb/dragonfly > > * Perhaps more. > > > > I don't know how compatible they are with the Redis API. I can't > > afford working on this right now and in the foreseeable future, I see > > it almost as a second library of a module of my library e.g. > > aedis::redis::search::request or something. > > Ok, this is something different. If you don't want to break support > for those other DBs, that's understandable. But since you don't have > support for them at the moment, I don't think possibly adding support > for those later (which could also be added in much the same way) > should slow down adoption of a better interface for Redis today. > > Zach

1 0

Implemented support for recvmmsg / sendmmsg (on supported operating systems: Linux / *BSD / AIX / QNX)
by Virgilio Fornazin 17 Jan '23

17 Jan '23

As stated on asio-users mailing list ( https://sourceforge.net/p/asio/mailman/asio-users/thread/CADfydx%2BDF1kvqch… ), I wrote a patch that enables sendmmsg / recvmmsg on supported operating systems (Linux, [Free/Net/Open]BDS, AIX, Blackberry QNXNeutrino). The syscalls are implemented in reactive_socket_service backend (the io_uring backend on Linux does not support sendmmsg / recvmmsg yet, so no recvmmsg / sendmmsg when using newest support for io_uring on asio). The config.hpp has macros for forcible disable those calls, and detect supported operating system compiler macros. New methods were developed for (send/send_to/receive/receive_from) suffixed with '_multiple_buffer_sequence' that accepts a multiple_buffer_sequence class (backed by asio::detail::array<multiple_buffer_sequence_op, N> or std::vector<multiple_buffer_sequence_op>) and a multiple_buffer_sequence_adapter that convert ops to struct mmsghdr* for sendmmsg/recvmmsg. The multiple_buffer_sequence implementations are basically a collection of multiple_buffer_sequence_op instances that represents each socket operation . It defines the objects needed to perform fill on mmsghdr structures buffer_sequence_type buffer_sequence_; buffer_sequence_adapter_type buffer_sequence_adapter_; endpoint_type endpoint_; bool completed_; socket_base::message_flags flags_; std::size_t bytes_transferred_; asio::error_code error_code_; The multiple_buffer_sequence implementations has full container support, iterators, and support Mutable and Const buffer sequences. I finished the first version of the patch. It's able to send and receive 1million packet / second on my box at same time (an intel i9 9900k / ubuntu 22.04 lts low latency kernel) using packet sizes of 64 / 1430 bytes without packet loss (using 64mb udp socket buffers) A little running demo is able to being watched at https://www.youtube.com/watch?v=Q3hqe6ntM3w. I need to write some automatic tests for (async_)[send/receive]_multiple_buffer_sequence calls[_to/_from] and push a pure ASIO example in examples repository I made the code available for review, scrutiny and suggestions. The source code is in my github repo ( https://github.com/virgiliofornazin/asio ),on branch feature/multiple_datagram_buffers_sequence-io-sendmmsg-recvmmsg ( the full URL of patch diff is https://github.com/chriskohlhoff/asio/compare/master...virgiliofornazin:asi… ).

2 7

Regression Results Not Updating
by Tom Kent 15 Jan '23

15 Jan '23

The results from the pages at: https://www.boost.org/development/tests/develop/developer/summary.html https://www.boost.org/development/tests/master/developer/summary.html Have not updated in almost a month. Can someone check on the process that manages this? Thanks, Tom

4 10

delayed_forward: good, bad, ugly?
by Hans Dembinski 12 Jan '23

12 Jan '23

Dear all, a user noticed that some classes in Boost.Histogram do not provide a strong exception guarantee, although with a few changes they could. I never promised that guarantee for those classes, but I am inclined to support it. To that end, I am considering use a type called delayed_forward to the public interface of that class. I would like to get a mini-review on the concept. The change is backward-compatible and it offers some advantages, so it seems like a good solution to me, but maybe I am missing some caveats. The constructor of my class, let’s call it Foo, accepts some potentially non-trivial parameters by value, because I didn’t want to write an interface with a templated forward reference. Passing non-trivial parameters by value is cheap if the compiler can do RVO or if the user calls the move constructor via std::move. Not using a forward reference saves a few template instantiations and thus reduces compile time. I think I got that from Herb Sutter in a GotW entry, but I cannot find it right now. With delayed_forward one can efficiently pass values to Foo with a single ctor. The trade-off is a tiny runtime cost, but that’s ok if we know that Foos are not created en mass in a hot loop. That already guided my choice of passing by value. A minimal demo is here: https://godbolt.org/z/z71E1jno1 The design of delayed_forward is so simple that it probably already exists somewhere, likely under another name. Maybe even in Boost. What do you think? Hans

5 13

Upcoming aedis review
by Klemens Morgenstern 10 Jan '23

10 Jan '23

The aedis review will start in less than a week, on the 15th and last until the 24th of this month. Aedis is a Redis client library built on top of Boost.Asio that implements the latest version of the Redis communication protocol RESP3. Some of its distinctive features are * A connection class that provides high-level functions to execute Redis commands and receive server pushes concurrently. * Automatic pipelining of commands. * Support for STL containers and serialization of user-defined data types. * Low-latency: Responses can be read in their final data-structure without creating copies. Aedis links Github: https://github.com/mzimbres/aedis Documentation: https://mzimbres.github.io/aedis/ Git tag: v1.4.1 Tarball: https://github.com/mzimbres/aedis/archive/refs/tags/v1.4.1.tar.gz Redis Links: Redis: https://redis.io/ RESP3: https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md Pipelines: https://redis.io/docs/manual/pipelining/ Redis commands: https://redis.io/commands/ Running Redis: Redis can be also easily installed on your local machine, for example, on Debian run "apt install redis". You might also want to use docker https://www.docker.com/blog/how-to-use-the-redis-docker-official-image/ Please consider writing a review next week.

1 0

CMake documentation (mostly) available
by Peter Dimov 07 Jan '23

07 Jan '23

I've written a document that explains how to use CMake to build or consume Boost, at https://github.com/boostorg/cmake/blob/develop/README.md This targets users of Boost. Developer-centric documentation is also available at https://github.com/boostorg/cmake/blob/develop/developer.md This is still unfinished, but I decided to "publish" it because the portions that are present are still (hopefully) valuable.

1 0

Fwd: CircleCI Security Alert - 4 Jan 2023 - Rotate any secrets stored in CircleCI
by Marshall Clow 05 Jan '23

05 Jan '23

I received this today….. — Marshall > Begin forwarded message: > > From: CircleCI <security(a)circleci.com> > Subject: CircleCI Security Alert - 4 Jan 2023 - Rotate any secrets stored in CircleCI > Date: January 4, 2023 at 6:30:49 PM PST > To: marshall(a)idio.com > Reply-To: security(a)circleci.com > > <https://go.circleci.com/NDg1LVpNSC02MjYAAAGJHrz8WLiocAliTEINy0V4BGCeC4xesDl…> > We wanted to make you aware that we are currently investigating a security incident, and that our investigation is ongoing. We will provide you updates about this incident, and our response, as they become available. At this point, we are confident that there are no unauthorized actors active in our systems; however, out of an abundance of caution, we want to ensure that all customers take certain preventative measures to protect your data as well. > > Action request: > > Out of an abundance of caution, we strongly recommend that all customers take the following actions: > Immediately rotate any and all secrets stored in CircleCI. These may be stored in project environment variables or in contexts. > We also recommend customers review internal logs for their systems for any unauthorized access starting from December 21, 2022 through today, January 4, 2023, or upon completion of your secrets rotation. > Additionally, if your project uses Project API tokens, we have invalidated those and you will need to replace them. You can find more information on how to do that in our documentation here. <https://go.circleci.com/NDg1LVpNSC02MjYAAAGJHrz8WBmOiXzPovREibkXKh8Iqcsacum…> > > We apologize for any disruption to your work. We take the security of our systems and our customers’ systems extremely seriously. While we are actively investigating this incident, we are committed to sharing more details with customers in the coming days. > > Thank you for your urgent attention to rotating your secrets.

1 0

Aedis scheduled for review
by Mateusz Loskot 04 Jan '23

04 Jan '23

Folks, I'd like to thank Klemens Morgenstern for stepping forward and volunteering as a review manager of the Aedis library. The Aedis review will take place between the dates of January 15, 2023 - January 24, 2023 https://www.boost.org/community/review_schedule.html Please, polish your guns and look forward to receiving the start of the review announcement from Klemens. Best regards, -- Mateusz Loskot on behalf of Boost Review Wizards

4 8

Mustache scheduled for review
by Mateusz Loskot 04 Jan '23

04 Jan '23

Folks, I'd like to thank Klemens Morgenstern for volunteering as a review manager of the Mustache library, and Peter Dimov for submitting the library. The Mustache review will take place between the dates of February 5, 2023 - February 14, 2023 https://www.boost.org/community/review_schedule.html As usual, the review manager will announce the beginning of the review with details. Best regards, -- Mateusz Loskot on behalf of Boost Review Wizards

1 0

Updating Review Schedule
by Mateusz Loskot 03 Jan '23

03 Jan '23

Happy New Year Everyone! On behalf of the Review Wizards Team, I'm updating the review schedule. It looks like we will be enjoying two reviews this month yet: - Aedis by Marcelo Zimbres Silva (start planned for Jan, 15) - Mustache by Peter Dimov (start planned not too long after aedis review) Before I issue official announcements, if there are any objections to this plan, then please express them now. Best regards, Mateusz Loskot

2 2

New Boost library proposal, Mustache
by Peter Dimov 30 Dec '22

30 Dec '22

I'm looking for endorsements and a review manager volunteer for a new library, Boost.Mustache. It's an implementation of Mustache templates (http://mustache.github.io/) in C++11 and at the moment supports the mandatory portions of the Mustache spec (https://github.com/mustache/spec) The repository is https://github.com/pdimov/mustache. Mustache is a simple templating language in which tags of the form {{something}} are replaced with the value of the entity `something`, which typically means with the member "something" of the JSON object passed when rendering the template. Boost.Mustache can take a Boost.JSON object as the context against which data references are resolved, but it can also take arbitrary values that can be converted to boost::json::value by using boost::json::value_from. This allows, for instance, described classes (structs and classes annotated with Boost.Describe) to be passed as the data context, such that references to e.g. {{title}} in the template are resolved to the corresponding `title` member of the class. A simple usage example demonstrating the above is: ``` #include <boost/mustache.hpp> #include <boost/describe.hpp> #include <iostream> struct item { std::string title; std::string author; std::string link; }; BOOST_DESCRIBE_STRUCT(item, (), (title, author, link)) struct reference { std::string heading; std::vector<item> items; }; BOOST_DESCRIBE_STRUCT(reference, (), (heading, items)) int main() { reference ref = { "Reference", { { "Better Bit Mixing - Improving on MurmurHash3's 64-bit Finalizer", "David Stafford", "https://zimbry.blogspot.com/2011/09/better-bit-mixing-improving-on.html" }, { "Stronger, better, morer, Moremur; a better Murmur3-type mixer", "Pelle Evensen", "https://mostlymangling.blogspot.com/2019/12/stronger-better-morer-moremur-b…" }, { "Improved mx3 and the RRC test", "Jon Maiga", "http://jonkagstrom.com/mx3/mx3_rev2.html" } } }; std::string tmpl = R"(<html> <body> <h1>{{heading}}</h1> <ul> {{#items}} <li> <strong>{{title}}</strong><br> <em>{{author}}</em><br> <a href="{{link}}">{{link}}</a> {{/items}} </ul> </body> </html>)"; boost::mustache::render( tmpl, std::cout, ref, {} ); } ``` The resulting output is <html> <body> <h1>Reference</h1> <ul> <li> <strong>Better Bit Mixing - Improving on MurmurHash3's 64-bit Finalizer</strong><br> <em>David Stafford</em><br> <a href="https://zimbry.blogspot.com/2011/09/better-bit-mixing-improving-on.html">https://zimbry.blogspot.com/2011/09/better-bit-mixing-improving-on.html</a> <li> <strong>Stronger, better, morer, Moremur; a better Murmur3-type mixer</strong><br> <em>Pelle Evensen</em><br> <a href="https://mostlymangling.blogspot.com/2019/12/stronger-better-morer-moremur-b…">https://mostlymangling.blogspot.com/2019/12/stronger-better-morer-moremur-b…</a> <li> <strong>Improved mx3 and the RRC test</strong><br> <em>Jon Maiga</em><br> <a href="http://jonkagstrom.com/mx3/mx3_rev2.html">http://jonkagstrom.com/mx3/mx3_rev2.html</a> </ul> </body> </html>

5 5

Tribute to John Kalb
by Robert Ramey 27 Dec '22

27 Dec '22

It's the end of 2022. I wanted to take a moment to recognize the contributions to Boost over the last dozen years or so by Jon Kalb. I first met Jon at a Microsoft Meeting named "Going Native" which was promoting a "resurgence" of C++ over Languages like Java and C#. It seems that this was related to the C++ committee incorporating large parts of Boost into the standard library and Microsofts renewed commitment to C++. This is my take, I'm sure someone else could provide more details on this. My view that was that there wasn't much more for Boost to do. Dave Abrahams was moving on to bigger things which reinforced this impression. Jon was enthusiastic about taking the lead on Boost. It was clear that he and I had a different visions. I sort of cringed - it looked to me like he got suckered. He asked me if I planned to attend C++Now - I weaseled out of actually answering. Of course he turned out to be right and I was wrong. The C++ committee hasn't really been able to replace Boost. It's too slow and cumbersome. Working as a design committee isolated from actual implementation doesn't seem to conducive to designing good, clean, elegant software. And it takes forever. It's odd to me that the committee adopted a large part of Boost software, but failed to learn anything from Boost about how to make this kind of stuff. So in this environment Jon led Boost. He worked from top to bottom on all the stuff that needs to be done - finances, legal, C++Now planning, recruitment of collaborators, etcetra . Very successful and, like many successful people, made it look easy. Hence he has not been appreciated to the extent he should be. Now he as moved on from Boost - he will be missed. Apparently this was in the works for some time but was pushed along by complaint about his handling about an alleged code of conduct violation which in my view was blown way out of proportion. I think the Boost BOD has treated Jon shabbily regarding this incident. My aim here is to correct that. Boost has had a large role in saving C++ from decline into obscurity. David Abrahams and Beman Dawes were the primary promoters at Boost at it's start. I don't think it's too much to say that these two persons saved C++. To this list, I'd like to add the name of Jon Kalb, without whom Boost would likely have wound down with C++11. -- Robert Ramey www.rrsd.com (805)569-3793

4 3

Why do Predef and Config exist?
by Hans Dembinski 27 Dec '22

27 Dec '22

Hi all, since there were concerns that the email list is so quiet, here is some noise. Is someone willing to explain to me why we have Predef and Config? It looks like these two libraries have a strong overlap in scope. Shouldn’t they be merged? Best regards, Hans

10 15

Proposing a Redis client library for inclusion in Boost
by Marcelo Zimbres Silva 22 Dec '22

22 Dec '22

Hi, I would like to propose my Redis client library for inclusion in Boost Github: https://github.com/mzimbres/aedis Homepage: https://mzimbres.github.io/aedis Redis: https://redis.io Aedis implements asynchronous communication with a Redis server using the RESP3 protocol [1] and is built on top of Boost.Asio, which makes it similar to Boost.Beast and Boost.MySql. For more information, please, refer to the project homepage. I am looking for someone who would like to endorse the library and also for a review manager. Thanks, Marcelo [1] https://github.com/redis/redis-specifications/blob/master/protocol/RESP3.md

5 5

[Test] How to make test framework create Core dump in case of any unhandled exceptions?
by Sergey P 21 Dec '22

21 Dec '22

Dear developers, Is it possible to force Boost.Test framework to create Core dump in case of catching any kind of unhandled exception from code that is being tested? We tried to use parameter: *--catch_system_error=no* but it creates core dump for system signals only, while we need core dump for any exceptions, even custom ones. We would appreciate any suggestions or hints. Thank you very much! Best regards, Sergey Podolyan

1 0

[release] Boost 1.81.0
by Marshall Clow 17 Dec '22

17 Dec '22

Release 1.81.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains one new library and numerous enhancements and bug fixes for existing libraries. * URL: A library for parsing, modifying, and printing URLs using only C++11, from Vinnie Falco and Alan de Freitas. For details, including download links, see <http://www.boost.org/users/news/version_1.81.0> You can also download directly from: <https://boostorg.jfrog.io/artifactory/main/release/1.81.0/> To install this release on your system, see <http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. -- The Boost Release Team Marshall Clow, Glen Fernandes, Michael Caisse

3 2

Master is open for merges
by Glen Fernandes 15 Dec '22

15 Dec '22

Master is open again, with no restrictions. Boost version numbers bumped (boost, config, more), and new release notes stubbed (website). Glen

1 0

[release] Boost 1.81.0 Release Candidate 1 is available
by Marshall Clow 14 Dec '22

14 Dec '22

The first release candidates for the 1.81.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.81.0/source/> The SHA256 checksums are as follows: 205666dea9f6a7cfed87c7a6dfbeb52a2c1b9de55712c9c1a87735d7181452b6 boost_1_81_0_rc1.tar.gz 6e689b266b27d4db57f648b1e5c905c8acd6716b46716a12f6fc73fc80af842e boost_1_81_0_rc1.zip d7bc4e2a2aee374a8c24832cacfed1265680c1e824d09fab3e00f87508155353 boost_1_81_0_rc1.7z 71feeed900fbccca04a3b4f2f84a7c217186f28a940ed8b7ed4725986baf99fa boost_1_81_0_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

10 15

Revitalization
by David Sankel 09 Dec '22

09 Dec '22

Hi all, At C++Now this year I gave a talk on the status of Boost and presented this graph which illustrated the trend of Boost mailing list participation. https://docs.google.com/presentation/d/1ocX8Dh4B98gxfXJTWOriaEU1tmJN61M4Rfj… I'm interested to hear your opinions as to what happened over that time period to cause such a trend. There's truth to the claim that this question is being asked of the wrong people; those who left, stopped participating, or would otherwise start probably have good insight. Nevertheless, I think it would be interesting for us to brainstorm on this. Thanks in advance for your thoughts. -- David

26 62

[ASIO] boos::asio::basic_streambuf does not accept user defined size during construction. Still defaults to 128
by Aniket Pugaonkar 09 Dec '22

09 Dec '22

Hello, I was checking the implementation of boost streambuf and noticed that buffer_delta value is defaulted to 128, which results in the capacity of the container to 128 bytes by default, and based on that, there is no way to change it even if we provide max size as some custom number (say 9000 for receiving an encapsulated packet on socket). The initial allocation (buffer_.resize is done with 128. But when we call *buf.prepare(9000)*, it again results in resize(n) operation (through reserve(n) function call. Is there any other way to change this other than modifying the constructor in our codebase to provide a user defined value of buffer_delta Not sure if this needs to be enhanced. the maximum_size argument seems to be of no use in this case. Kindly advise for the same. For time being, I modified the library code to the following to ensure it does not break the default argument, but accepts user defined value. Alternatively, I can change buffer delta to be of larger value, but don't want to end up with a large buffer for no reason. if (max_size_ == std::numeric_limits<std::size_t>::max()) pend = (std::min<std::size_t>)(max_size_, buffer_delta); else pend = std::max<std::size_t>(max_size_, buffer_delta); Regards Aniket. -------------------- original code ---------------- enum { buffer_delta = 128 }; /// Construct a basic_streambuf object. /** * Constructs a streambuf with the specified maximum size. The initial size * of the streambuf's input sequence is 0. */ explicit basic_streambuf( std::size_t maximum_size = (std::numeric_limits<std::size_t>::max)(), const Allocator& allocator = Allocator()) : max_size_(maximum_size), buffer_(allocator) { *std::size_t pend = (std::min<std::size_t>)(max_size_, buffer_delta);* *buffer_.resize((std::max<std::size_t>)(pend, 1));* setg(&buffer_[0], &buffer_[0], &buffer_[0]); setp(&buffer_[0], &buffer_[0] + pend); }

1 0

Biuld boost with MSVC
by Mauro Ziliani 09 Dec '22

09 Dec '22

Hi all. My name's Mauro. I need to build boost 1.80.0 against v141_xp MSVC toolset. Which is the correct syntax for bootstrap ot b2? Best regards, MZ -- https://www.linkedin.com/in/mauroziliani

1 0

[release] Master Branch is closed for all changes
by Marshall Clow 08 Dec '22

08 Dec '22

The master branch is closed for all changes. Release expected on 14-Dec-2022 - Release Managers

1 0

missing patch
by Gero Peterhoff 07 Dec '22

07 Dec '22

Hi Matt, i'm missing patch #871/#872 (https://github.com/boostorg/math/issues/871) in 1.81rc2. thx Gero

2 3

Master branch is now open for bug fixes
by Marshall Clow 07 Dec '22

07 Dec '22

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 The next deadline: On December 7th, master closes for all changes. As always, the calendar is at https://www.boost.org/development/ <https://www.boost.org/development/> — Marshall

12 27

Boost.Text is looking for a (mini-)review manager
by Zach Laine 07 Dec '22

07 Dec '22

I've made all the recommended changes to Boost.Text that came up in the review. Glen, the previous review manager, recommended a mini review of Boost.Text once I'd made those changes. If you'd like to manage the mini-review, please let me know. For everyone, including potential reviewers and review managers, here are the major changes: * All the specific review feedback issues have been addressed. * The string layer is now gone. * The text layer got a major re-work. It is now a set of template-based adaptors (basic_text<>, vs. a text typedef. etc.), which lets everyone get what they want. You can change the underlying storage type (including whatever allocator you prefer), select UTF-8 or UTF-16, and change the normalization form. Glen recommended I drop this layer, but the library is way less useful without this stuff, and these changes address all the concerns raised about the text layer in the review. The updated docs can be found here: https://tzlaine.github.io/text/doc/html/index.html Oh yeah, and I added concept constraints to the whole library when you build in C++20 mode. Zach

17 46

Re: [boost] Revitalization
by William Linkmeyer 07 Dec '22

07 Dec '22

For bringing up new talent, I agree with Niall. For Boost’s usage, I maintain that new libraries in the hardware space are useful — audio, visual, libraries. No great ones exist. For C++ as a whole, I’m not sure I would recommend this language to newcomers until we break ABI and more of the cppfront syntax & safety is introduced. Our hashing and regex performance is embarrassing. Our syntax is cluttered. We can and should solve those problems. WL > On Dec 6, 2022, at 6:44 PM, Gavin Lambert via Boost <boost(a)lists.boost.org> wrote: > > On 7/12/2022 10:42, Robert Ramey wrote: >> c) use the boost tool (I forget the name) to scan my code and list the required source modules >> d) include those source files in my b2 or CMake file. > > These steps are atypical. Most users will run b2 to build binaries (static or dynamic) and then link with these, or will use the prebuilt bintray or whatever binaries, or the prebuilt Linux distro binaries. > > While it's possible to import individual .cpp files, that's never the encouraged method to depend on any C++ libraries, Boost or otherwise. > > > _______________________________________________ > Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

boost::streambuf default size/capacity still set to 128 in spite of size provided in constructor.
by Aniket Pugaonkar 05 Dec '22

05 Dec '22

Hello, I was checking the implementation of boost streambuf and noticed that buffer_delta value is defaulted to 128, which results in the capacity of the container to 128 bytes by default, and based on that, there is no way to change it even if we provide max size as some custom number (say 1500 for receiving a packet on socket). The initial allocation (buffer_.resize is done with 128. But when we call *buf.prepare(1500)*, it again results in resize(n) operation (through reserve(n) function call. Is there any other way to change this other than modifying the constructor in our codebase to provide a user defined value of buffer_delta Not sure if this needs to be enhanced. the maximum_size argument seems to be of no use in this case... Kindly advise. Regards Aniket. /// Construct a basic_streambuf object. /** * Constructs a streambuf with the specified maximum size. The initial size * of the streambuf's input sequence is 0. */ explicit basic_streambuf( std::size_t maximum_size = (std::numeric_limits<std::size_t>::max)(), const Allocator& allocator = Allocator()) : max_size_(maximum_size), buffer_(allocator) { *std::size_t pend = (std::min<std::size_t>)(max_size_, buffer_delta);* *buffer_.resize((std::max<std::size_t>)(pend, 1));* setg(&buffer_[0], &buffer_[0], &buffer_[0]); setp(&buffer_[0], &buffer_[0] + pend); } -- Thanks and regards, Aniket Pugaonkar

1 0

Reminder: Release notes
by Marshall Clow 29 Nov '22

29 Nov '22

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

2 1

[release] Boost 1.81.0 beta 1 released
by Marshall Clow 24 Nov '22

24 Nov '22

Boost release 1.81.0 beta 1 is now available at: https://boostorg.jfrog.io/artifactory/main/beta/1.81.0.beta1/source/ The SHA256 checksums are: 135f03965b50d05baae45f49e4b7f2f3c545ff956b4500342f8fb328b8207a90 boost_1_81_0_b1.tar.gz 736b041748d04c573d145613161cf2e54beb210c5511b67e6fac5510b82b6646 boost_1_81_0_b1.7z 941c568e7ac79aa448ac28c98a5ec391fd1317170953c487bcf977c6ee6061ce boost_1_81_0_b1.tar.bz2 c58d50acf58a98d4f5a7d891257d154efa50ca90312ca446586c7b4f9b7d3f14 boost_1_81_0_b1.zip Release notes (still need updates): https://www.boost.org/users/history/version_1_81_0.html Please try the beta and report any problems you encounter. Thanks to everyone who contributed to the release. -- Boost Release Team

3 2

GSoC 2023
by David Bellot 21 Nov '22

21 Nov '22

Dear Boost developers, organization applications for the Google Summer of Code 2023 will start next year in January, that is in about 2 months from now. In order to prepare the application for Boost C++, I would like to have a list of interested mentors and the topics they would like to propose to their students. The Google Summer of Code is a good opportunity for Boost to try ideas or improve existing libraries. Contact me now if you have any questions and are interested in mentoring next summer. Cheers, David

4 4

minor incident report, boost.org
by Sam Darwin 16 Nov '22

16 Nov '22

Hi, This morning around 7am PST the boost.org website appeared to be unavailable. Upon investigation the cause of the problem was traced to DNS. boost.org resolved in DNS. However boost.org redirects to www.boost.org and that failed to resolve at the upstream DNS provider. # nslookup > server dns1.easydns.com > www.boost.org Server: dns1.easydns.com Address: 2400:cb00:2049:1::a29f:1835#53 ** server can't find www.boost.org: REFUSED A "dig" command also showed "..Request blocked by policy". After an hour or so, the situation cleared up. Most likely something at easydns.com. A similar event occurred earlier this year. The C++ Alliance has set up web proxies to alternative domains boostcpp.org and boostlibraries.org in case boost.org is unavailable. Those were online and may be used as a backup. Best Regards, Sam Darwin sam(a)cppalliance.org

1 0

Boost tarball release that works with CMake
by Mojca Miklavec 16 Nov '22

16 Nov '22

Dear developers, For a CMake-based project we need to fetch Boost sources as part of the build process (unless boost is already installed, in which case that version can be used). We are using CMake's FetchContent that recursively clones the repository from GitHub, but that process is extremely slow. On the Windows runner in GitHub actions it takes roughly 3 extra minutes to "git clone" boost alone (or 11 minutes for something like "choco install boost-msvc-14.3"). I tried to fetch the .7z file instead, but that one doesn't work because the CMake support gets stripped from the distributed sources when generating the tarballs. A single file would result in a much faster and more reliable workflow. The file can be cached on GitHub Actions, on a local computer one doesn't need to repeatedly clone the repository (which also slows down other parts of CMake) etc. I started the discussion here: https://github.com/boostorg/release-tools/pull/35 where it has been explained to me that: - either the CMake support needs to be heavily refactored (unlikely to happen soon) - or the project could generate one tarball using the layout that's consistent with git repository The second option might eventually be fulfilled automatically by GitHub, but that is probably not likely to happen any time soon either. I can imagine that creating one extra '.tar.xz' with a slightly different layout to support CMake builds might be straightforward to make. Is there any chance to fulfill my dream to be able to build a boost tarball with CMake out-of-the-box? Thank you very much, Mojca

7 10

The C++ Alliance
by Louis Tatta 15 Nov '22

15 Nov '22

Hello, my name is Louis Tatta and I am the CEO of The C++ Alliance, a non-profit founded by Vinnie Falco to support and bolster the C++ ecosystem through open source and education. This serves as a formal introduction and description of our recent activities to support Boost. As you all know, Travis CI (continuous integration) became unusable for Boost needs over a year ago. To ensure the availability of CI services, our CTO and chief of devops Samuel Darwin (“Sam”) has deployed Drone CI, an open source continuous integration framework, onto scalable Amazon Web Services instances rented by us. Over the last year there has been some turnover in terms of key individuals who administer the Boost website and support the Boost release process. We have made Sam’s time and expertise available to the Boost organization to support the release managers and core developers as needed to resolve IT issues. Vinnie has outlined a vision for revitalizing Boost by developing a new, modern website to stimulate technical discussion and publication of educational resources and ideas. To this end we have retained a design firm and the leading Python development house to build a new interactive website for Boost. The designs have been completed, and the coding for the website has been underway now for almost a year. Given the current trajectory we estimate that this project will be ready for internal viewing, testing, and feedback by authors and maintainers at the end of Q1 2023. Our current engineer staffing and projects are as follows: Klemens Morgenstern, a full-time Staff Engineer, is maintaining the Boost.Beast library and developing a new high client library built on Beast and Asio. Alan de Freitas, a full-time Staff Engineer, has been working on Boost.URL (now accepted) for the last year and has also taken over maintenance of Boost.StaticString. Dmitry Arkhipov, a part-time Staff Engineer is maintaining Boost.JSON, adding new features with guidance from Peter Dimov. Christian Mazakas, a full-time Staff Engineer and Joaquín M López Muñoz, a part-time Staff Engineer, have been working on the Boost.Unordered improvement project which is overseen by Peter Dimov. If anyone has questions about any of this please feel free to ask, or reach out to me by email.

1 0

[release] Boost 1.81.0 Beta 1 Release Candidate 2 is available
by Marshall Clow 15 Nov '22

15 Nov '22

Unfortunately, people found a few problems in the RC1 (Thanks to everyone who tried it, and especially to those who reported problems) We now have a RC2, available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.81.0.beta1/source/> The SHA256 checksums are as follows: bff5cf561ab65be658c030f6b348a4907cce039611e96112dc8f6e27b6a9f44b boost_1_81_0_b1_rc2.7z 7f300d48189b9f25bf3b214168912043681819f0ace332b0e9de503f7e23e72c boost_1_81_0_b1_rc2.tar.bz2 1619545e2f180caf6615eb83220ebcc1342c20704307b59871d987b95adb1326 boost_1_81_0_b1_rc2.tar.gz 3f9ebb8b23cab1617a7ae9a38b251e4803c917832b0c4c96b907cf122dec428f boost_1_81_0_b1_rc2.zip The changes are: 1) Fixed a compile error in Boost.ASIO 2) Fixed several compilation errors on Mac OS with libstdc++. (Boost.Config) 3) Fixed Boost.JSON compilation error with X11 4) Fixed a crashing but on shared_ptr on PPC (Boost.Sharedptr, Boost.Align) 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

2 2

[Release] Boost 1.81.0 closed for beta
by Marshall Clow 14 Nov '22

14 Nov '22

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

3 3

[release] Boost 1.81.0 Beta 1 Release Candidate 1 is available
by Marshall Clow 13 Nov '22

13 Nov '22

Available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.81.0.beta1/source/> The SHA256 checksums are as follows: 6b6b95fde0ec9c6c0e1584f35c6c2dc4eb6c8629c9635e844b8e6a9ad9594da1 boost_1_81_0_b1_rc1.tar.gz 9f2ce5d1cefb8f6b7e8cfcabc73632f348958e7cba2604dcb3688fecf6463d67 boost_1_81_0_b1_rc1.tar.bz2 e7547a789339499c6fc582a96ffb8989d97074f107520ddebc1ed5f30a0d6964 boost_1_81_0_b1_rc1.zip 758af4ae4f4224b6f2bd8f05fe0109d1f248c0377ee2dce03ccbeb30d82fb8b4 boost_1_81_0_b1_rc1.7z 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

8 10

ccmath::abs() gives wrong result
by Gero Peterhoff 11 Nov '22

11 Nov '22

Hi Matt, ccmath::abs() gives wrong result for FP-values std::numeric_limits<FP-Type>::min() in constexpr context. test case: using type = float; constexpr type a = std::numeric_limits<type>::min(), b = boost::math::ccmath::abs(a); std::cout << a << std::endl << b << std::endl; 1.17549e-38 nan The Problem is: template <typename T> inline constexpr T abs_impl(T x) noexcept { return boost::math::ccmath::isnan(x) ? std::numeric_limits<T>::quiet_NaN() : boost::math::ccmath::isinf(x) ? std::numeric_limits<T>::infinity() : x == -0 ? T(0) : x == (std::numeric_limits<T>::min)() ? std::numeric_limits<T>::quiet_NaN() : x > 0 ? x : -x; } In the case of FP-types, only the sign-bit has to be deleted, since one cannot assume that quiet_NaN() and/or signaling_NaN() are always unsigned. thx Gero

2 1

Boost 1.81.0 closed for major changes
by Glen Fernandes 09 Nov '22

09 Nov '22

Release has closed for major changes. Next week, 2022/11/09, master closes for all changes, in preparation for the beta. - Release team

3 3

Build Issue - URL - msvc-14.0
by Tom Kent 05 Nov '22

05 Nov '22

In preparation for the upcoming lockdown and release, I just grabbed the latest snapshot from here: https://boostorg.jfrog.io/artifactory/main/master/boost_1_81_0-snapshot.tar… I ran it through the build process and got some issues with boost::url running on msvc-14.0. Some examples of them are: D:\RB\boost_1_81_0\boost/url/param.hpp(886): error C2134: 'boost::urls::grammar::string_view_base::string_view_base': call does not result in a constant expression D:\RB\boost_1_81_0\boost/url/param.hpp(886): note: failure was caused by call of undefined function or one not declared 'constexpr' The full output log is here: https://gist.github.com/teeks99/8d14da5b50cffda13f9ad5e23a8d80aa Tom

3 4

Does ASIO really still uses reactor instead of proactor on some OSes or is documentation just outdated?
by Ivan Matek 29 Oct '22

29 Oct '22

If you go to https://www.boost.org/doc/libs/1_80_0/doc/html/boost_asio/overview/core/asy… you will see that it says: * On many platforms, Boost.Asio implements the Proactor design pattern in terms of a Reactor, such as select, epoll or kqueue. This implementation approach corresponds to the Proactor design pattern as follows: * *[...]* * On Windows NT, 2000 and XP, Boost.Asio takes advantage of overlapped I/O to provide an efficient implementation of the Proactor design pattern. This implementation approach corresponds to the Proactor design pattern as follows: * I am unfortunately not a pattern or OS expert, but I would expect that on every modern OS proactor can be implemented without using reactor, e.g. see *https://stackoverflow.com/a/57451551/700825 <https://stackoverflow.com/a/57451551/700825>* The fact that mentioned Windows are NT, XP and 2000 also furthers my suspicion that docs are outdated.

3 4

Boost.StaticString
by Vinnie Falco 29 Oct '22

29 Oct '22

Alan de Freitas has generously stepped up to maintain Boost.StaticString in the absence of Krystian. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

1 0

1.81.0 closed for new libraries and breaking changes
by Glen Fernandes 28 Oct '22

28 Oct '22

Next deadline: On 2022-11-02 Boost 1.81.0 closes for major code changes. Still open for serious problem fixes and docs changes without release manager review. - Boost release team

1 0

Wants to start contributing to boost libraries
by Shivam Rajput 28 Oct '22

28 Oct '22

Hey, I'm really interested to start contributing to boost, it would be really great if any of you could suggest which libraries that i can start with? Maybe any of the gsoc projects that need maintenance and more work? Currently I'm more interested in c++23 features and trying to implement some of them into libcxx. Thanks and regards Shivam

1 0

Reminder: Oct 26, 1.81.0 closed for new libraries and breaking changes
by Glen Fernandes 18 Oct '22

18 Oct '22

1.81.0 closes for new libraries and breaking changes next Wednesday (2022-10-26). We have two new accepted libraries: MySQL and URL, but only URL has been imported into the organization and has a submodule right now. Glen

3 2

New Library Proposal: xvec/simd
by Towner, Daniel 17 Oct '22

17 Oct '22

I would like to propose a SIMD/data-parallel header-only library for inclusion in boost. The library is an example implementation already developed by Intel of a C++ TS proposal called std::experimental::parallelism_v2::simd [1]. The library is styled as a data-parallel library where the programmer specifies the data parallelism available in the source program, and the compiler will generate the appropriate simd instruction sequences. The library is agnostic of simd element type and length, and within reason, should be able to target any processor with simd capabilities. Intel has added further generic extensions to the proposal, such as permutation operations and support for complex numbers [2]. Motivation: The concept of simd needs little introduction as the technique is widely used in high performance software and there are many libraries providing varying level of abstraction and portability. In [1], Matthias Kretz made a proposal to provide a standard C++ library which implements many data-parallel concepts in a portable, vendor-neutral style, and with tight integration with C++ (e.g., operator overloading, overloads for all appropriate standard library functions). That proposal and the feedback on it have been discussed in WG21 and Intel supports the proposal. There was an attempt to add a boost.simd library in the past but that was abandoned after its authors decided to commercialise it. Despite the availability of other simd or data-parallel libraries in the wider community there is still a gap for a data-parallel, width-agnostic, vendor neutral library with close integration into C++. The std::simd library proposal and its example implementation from Intel seem to fill this gap. The existence of an example implementation in boost will also make it easier to get users to adopt the TS and provide feedback to improve its API and feature set for real-world code. History: There are two strands of history that come together in this proposal: Intel's own vector libraries, and the C++ std::simd proposal. Intel has a long history of developing simd-capable processors and has its own libraries for accessing simd features [3]. A recent Intel project to refresh those libraries resulted in a new library called `xvec' which incorporates many modern C++ features and is deliberately vendor and target neutral, with the target being selected at compile-time. In 2013 the proposal was started, and then a C++ TS was published in 2018 [1] and discussed in WG21. Due to the similarities of the two libraries and their common goals, myself and Matthias Kretz are now working together on merging the simd specification from the Parallelism TS 2 into the IS for C++26. Status and Implementation: The `xvec' example library implemented by Intel supports most of the features of the std::simd proposal [1], along with a number of extensions to add some capabilities (e.g., generic permutation, complex number support) [2]. The library works in Linux and Windows, and can be compiled with GCC 12, LLVM 14 and Intel's oneAPI 2022. It is currently tested using googletest. Most of the library is implemented on top of the LLVM and GCC vector extensions [4], which makes it compilable on any target supported by those extensions. In a limited number of places intrinsics are used to access specific Intel instructions, but efficient generic fall-backs are also provided for simd targets which don't have those instructions (and this can included unsupported Intel processors too). Request: I would welcome any comments, questions or ideas on how to proceed with this proposal. [1] ISO/IEC TS 19570:2018, Programming Languages - Technical Specification for C++ Extensions for Parallelism, by Matthias Kretz. http://open-std.org/JTC1/SC22/WG21/docs/papers/2019/n4808.pdf [2] P2638R0: Intel's response to P1915R0 for std::simd parallelism in TS 2. https://wg21.link/p2638r0 [3] https://www.intel.com/content/www/us/en/develop/documentation/cpp-compiler-… [4] https://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-ve…

5 8

Github Actions slow
by Sam Darwin 12 Oct '22

12 Oct '22

On https://github.com/boostorg/json we have noticed very slow Github Actions times such as "Total duration: 6h 8m 47s" This is very likely caused by Github throttling jobs. https://docs.github.com/en/actions/learn-github-actions/usage-limits-billin… mentions limits of between 20 and 180 which would apply to the entire boostorg account. A reminder to any boost developers who are seeing slow processing time that they may use Drone CI, instructions at https://github.com/boostorg/boost-ci

4 3

Boost.URL examples
by Alan de Freitas 10 Oct '22

10 Oct '22

Hi, Would anyone like to suggest examples you'd like to see in Boost.URL? Best, -- Alan Freitas https://alandefreitas.github.io/alandefreitas/ <https://github.com/alandefreitas>

1 0

[checking interest] boost.tcl
by Klemens Morgenstern 01 Oct '22

01 Oct '22

Is there any interest in C++ Tcl bindings? I wanted to find out how far I can push boost.describe so I create C++ tcl binding based on it, PoC is here https://github.com/klemens-morgenstern/boost.tcl It's currently a rough PoC so it'd be a lot of work to make this a proper boost library, hence the question if there's some actual interest, otherwise it's a nice toy project. All you need to do is to use boost.describe for your enum or class and then you can use them in tcl: // C++ enum test_enum {foo = 1}; BOOST_DESCRIBE_ENUM(test_enum, foo); struct my_class { double foo; void bar(int); }; BOOST_DESCRIBE_STRUCT(my_class, (), (foo, bar)); BOOST_TCL_PACKAGE(Test_module, "1.0", mod) { auto & cmd = boost::tcl::create_command(mod, "test"); auto & enm = cmd.add_subcommand("enum"); enm.add_enum<test_enum>(); auto & fun = cmd.add_subcommand("add").add_function(+[](int i, int j) {return i + j;); auto & cl = cmd.add_subcommand("add") .add_class<my_class>() // adds all the members based on boost.describe .add_constructor<my_class(int, std::string)>(); } # TCL # create `test_enum` from it's int valid set e1 [test enum 1] # create test_enum from it's name set e2 [test enum foo] # call the function - overloading is supported [test add 1 2] # create an instance of my_class set mc [my_class new 1 test-string] # get a data-member puts [ *$mc .get foo ] # call a method *$mc bar 42

5 4

Re: [boost] [Boost-users] [signals2][variant] inline warning with MSVC 2022
by Frank Mori Hess 23 Sep '22

23 Sep '22

On Wed, Sep 21, 2022 at 12:21 PM Frank Mori Hess <fmh6jj(a)gmail.com> wrote: > > On Mon, Sep 19, 2022 at 3:16 AM Gavin Lambert via Boost-users > <boost-users(a)lists.boost.org> wrote: > > > > >,struct boost::mpl::l_iter<struct boost::mpl::l_end> > *)' marked > > as __forceinline not inlined > > > > I'm not sure whether the Real Bug™ is in signals2 or in variant, but I > > don't think it's in any of my code since it doesn't name any of my types > > above that I can see. > > The problem is not in signals2, as it makes no direct use of > __forceinline. variant does make use of BOOST_FORCEINLINE so it > probably needs to have the pragma suppression added somewhere. > Actually, maybe the easiest thing would be to just put the pragma suppression in the header that defines BOOST_FORCEINLINE (config/detail/suffix.hpp). -- Frank

5 13

[codecov] blowing up like the Hindenburg
by Vinnie Falco 20 Sep '22

20 Sep '22

All: Over the last 15 months, codecov.io has been undergoing a refactoring/rewriting of its user interface and in my opinion it is not for the better. There is a significant loss of functionality and the interface designs which have replaced the old designs are less usable. There's been an open issue for receiving feedback: <https://github.com/codecov/Codecov-user-feedback/issues/1> As you can see a lot of people are having problems. I have scheduled a call with the CEO. My purpose for this thread is to identify other Boost authors, maintainers, and users who have a stake in seeing codecov preserve its functionality and not get worse. And to show where you can go and complain if you are so inclined. Sam is investigating coveralls as an alternative solution. Its UI isn't quite as good as the old codecov. But it is better than the new codecov. Happy to hear anyone's thoughts on this matter. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

3 5

[range] Concept check failing with custom C++20 range support
by Jared McIntyre 19 Sep '22

19 Sep '22

I've been toying around with a pull request that was entered against boost::range to support integration of boost range_v2 and C++20 ranges to see how flexible it would be: https://github.com/boostorg/range/pull/123 I have a need to continue to use boost::any_range in some of our interfaces, but it would be nice to switch to using C++20 ranges under the covers. A lot of it seems to work well with the type definitions from the pull request, but I'm running into an issue with concept check on line 228 or any_iterator_wrapper.hpp specifically when using the transform adaptor. I don't have the same issue with boost::adaptors::transformed. What has me confused is that I think that the result views::transform should be forward traversal, but I'm not really clear on exactly why it is failing. I created a test if anyone wants to play around with it in a compiler and help me understand what is going on: https://godbolt.org/z/1hMsofbrv Switching between the two commented out base_range declarations will get you different results. Here is the code for anyone that just wants to look at it here: #include <boost/range.hpp> #include <boost/range/adaptors.hpp> #include <boost/range/any_range.hpp> #include <ranges> #if 1 namespace boost::range_detail { template< std::ranges::common_range C > struct range_mutable_iterator< C > { typedef std::ranges::iterator_t< C > type; }; template< std::ranges::common_range C > struct range_const_iterator_helper< C > { typedef std::ranges::iterator_t< C const > type; }; } #endif int main() { std::vector<int> vec(5, 0); auto mul2 = [](int i) { return i * 2; }; auto base_range = vec | std::views::transform(mul2); //auto base_range = vec | boost::adaptors::transformed(mul2); boost::any_range<int, boost::forward_traversal_tag> new_range = base_range; }

1 0

[dynamic_bitset] Add iterator feature
by GaoZIYU 11 Sep '22

11 Sep '22

I would like to support iterator feature by adding a few member functions, `begin()`, `end()`, `rbegin()`, `rend()` and their corresponding constant version. I think it's necessary for dynamic_bitset to have this feature through my thinking and other developer's opinions ( https://m.weibo.cn/5027267375/4757345970424490) Now I have submitted a pull request for the feature with code, docs and test case. Please review my code at your convenience. Thanks!

1 0

1.80.0 issue with Clang 15
by Peter Dimov 10 Sep '22

10 Sep '22

I'm getting multiple reports that ContainerHash 1.80.0 doesn't compile with Clang 15, due to the following change to Config unfortunately not being part of the 1.80.0 release: https://github.com/boostorg/config/commit/f0af4a9184457939b89110795ae2d2935… Since the plans for 1.80.1 have been abandoned, it's not clear what we can do about that except probably updating the Known Issues section.

3 2

How to know the connected server is down ?
by Raghu Huchchannavar 07 Sep '22

07 Sep '22

Hi, I am using the boost socket for the client and server connection. i set the socket option as below boost::asio::socket_base::keep_alive option(true); tcp_socket->set_option(option); I am able to connect the client to the server. Suppose after some time the server goes down. How do I get that information without sending any read/write request? 1. Now I don't know how to check if the client is down ? 2. Do I get the signal that the client is down? (Without reading or writing at the client )? . If yes, how to handle it. Please help me with this ... -- Regards Raghavendra Huchchannavar.

3 2

[Leaf] Unable to compile with particular flags.
by Misha Doter 06 Sep '22

06 Sep '22

Hi. I have a project ( https://github.com/rokoDev/buffer/tree/develop ) where I want to use Boost.Leaf as an error handling mechanism. And in addition I need to compile it by clang compiler with flags "-Werror -Wshadow-all -Wsign-conversion -Wextra" but it turned out that Boost.Leaf was unable to compile with these flags. So I have created a git fork( https://github.com/rokoDev/leaf/tree/clang_flags ) from official Boost.Leaf ( https://github.com/boostorg/leaf ) and made minimal changes which allowed me to build it with those flags. Also I have run all unit tests for Boost.Leaf on MacOS with success. Is it possible to accept my changes(probably with appropriate corrections if either) in order to allow compilation of any project with the same compiler flags as in my project but using the official version of Boost.Leaf?

3 4