- Boost - lists.preview.boost.org

[release] Boost 1.85.0 Release Candidate 2 is available
by Marshall Clow 11 Apr '24

11 Apr '24

The second release candidates for the 1.85.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.85.0/source/> The SHA256 checksums are as follows: 06bdbef025de63a22baf997d49d34f38455975529ee05ab73379338e572d0df4 boost_1_85_0_rc2.zip 623a9e5288bae94c0c01b733873ea12613af35f4fc433059a0ddaa5cf0033ce1 boost_1_85_0_rc2.tar.bz2 f7b6b252f488dc8a386bfc79bf7197772c4400f847f0dee50754bb23847d40d2 boost_1_85_0_rc2.7z ec9347228d2c8a7189685b48fe4609a837d3dde45973d4457a8f2396d2c446da boost_1_85_0_rc2.tar.gz The changes from RC1 are: * Boost.ASIO docs generate very long file names that are not usable on Windows. * Boost.Program options does not build in C++23 mode on clang truck (to be clang 19 before boost 1.86.0 is released) Note: It is possible that this is a bug in clang, and it’s in a clang that is not released yet. * Boost.Log has some broken links in its documentation. 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

7 10

Is there an interest for an async JSON-RPC library in boost ?
by Quentin Chateau 11 Apr '24

11 Apr '24

A couple of years ago, I wrote packio, a library implementing asynchronous client and server for msgpack-rpc. Over time it evolved into something more generic, an async implementation of the JSON-RPC (https://www.jsonrpc.org/) spec with customizable serialization. It is built on top of asio, and boost.json is supported serializer. This means that with minimal efforts it could evolve into an implementation of JSON-RPC with no dependencies outside of boost - yet extendable. My question then is: is there an interest for it ? I'd probably need to invest a non trivial amount of time into making it boost-compliant and following up on the review process, so I'm wondering whether it is worth it or not. Note that there are two known limitations in my library: - No support for batch mode - No support for sharing a transport between a client and a server (not part of the spec, but requested by some users) I'm looking forward to get the community's opinion. You can check my library on GitHub (https://github.com/qchateau/packio) Feedback on either community's interest for such library, or plain comments on the library are welcome ! Quentin

6 5

Fwd: A proposal for a modern build-system
by Daniele Lupo 11 Apr '24

11 Apr '24

On 23/03/2024 13:16, Hassan Sajjad wrote: > Hi. > > Could you please confirm if my proposal is under consideration? If so, > when can I expect an update regarding its status? > > Sorry for the delay, I had personal issues during those days. I've read the thread, and since now I can't see any serious issue or problem that make me think that the actual build system must be replaced. Maybe updated, but not replaced. For explaining more in detail my point of view (that, I will not ever repeat too many times, it's my personal one, so other people can have other ideas about it): - Boost does not pay people (as far as I know). You're asking for compensation in the first message, but nodoby will pay it, and nodoby asked for it. - I agree with others that three month of development are a bit too optimistic, and also in this case we must maintain two different build systems instead that one. - In the thread I've read many messages like "b2 can do this", "well, also hmake", but no messages like "hmake can do it and b2 it's not able to do it" "oh really? I'd love to have it!". I don't see any important use case that's requested by the community and that hmake will provide while b2 not. So the community wil use hmake to do the same things that at the moment it does with b2. - There's already another build system, even if not much official, and that's cmake. It works well and it's widely used, and that's supported by many package managers, like vcpkg. I have to say that hmake will not be used by them, so it will be limited to the scope of build boost like b2 actually does. Even in this case, it does not add anything. Basically, in the entire thread, in my opinion, there's not a single point that le me think that hmake will make the like easier to boost community. At most we'll have another tool that make the same things. And, repeating myself, I can see that new features actually not supported by b2, pratically modules, are easier to be implemented in b2 instead of using another build system and obligate the entire community to learn another tool for a feature that for now only a few of them will use. In addition to this, I strongly think that instead of a new build system I'll spend some effort, if necessary, in improving existing alternatives, like cmake, that are already widely used by the developer community around the world. Regards Daniele Lupo

4 6

[release] Boost 1.85.0 Release Candidate 1 is available
by Marshall Clow 08 Apr '24

08 Apr '24

The first release candidates for the 1.85.0 release are now available at: <https://boostorg.jfrog.io/artifactory/main/release/1.85.0/source/> The SHA256 checksums are as follows: de84c538aaadf2388362e006d73d0be783541288d87a9ef68e906995efc2148d boost_1_85_0_rc1.tar.gz dd8baccd0b5ca534ad3717a07b426391fe6d49b6b84bf07d10e72792a5d1ba10 boost_1_85_0_rc1.7z 289ab7784b9297e13938876f698ced91f734f9a80f91099d35803b78d15c0210 boost_1_85_0_rc1.tar.bz2 84c35ef72efde30725de7bca8ccf399cd8d205a0d5b249465cf86c818291b7b7 boost_1_85_0_rc1.zip 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 22

[release] status of the Boost release
by Marshall Clow 08 Apr '24

08 Apr '24

The RC1 has been tested, and three problems have been reported (so far) * Boost.ASIO docs generate very long file names that are not usable on Windows. * Boost.Program options does not build in C++23 mode on clang truck (to be clang 19 before boost 1.86.0 is released) Note: It is possible that this is a bug in clang, and it’s in a clang that is not released yet. * Boost.Log has some broken links in its documentation. And … Some additional libraries no longer build under C++03. (More than 1.84.0) The first one is the one that will impact the most people. Given that we want to fix that, we should fix the other two. I have asked the maintainers to merge the fixes to master. I will be out “watching the sky” tomorrow, but I will turn an RC2 either tomorrow night or Tuesday AM. This means that the release will almost certainly be delayed a couple of days past Wednesday. — Marshall

1 0

Interest in a library for type-safe bitwise operations?
by tobi＠die-loews.de 06 Apr '24

06 Apr '24

Hi, I would like to gauge interest in a library that makes the usage of flag-like enumerations safer. The library is called Boost.Flags, and its key features are - provides type-safe bitwise operations for flag-like scoped / unscoped enumerations - turns undetected logical errors into type errors Further characteristics are - non-intrusive - only a function overload or a template specialization required to opt-in - single header-file library - no dependencies (only standard-library includes) - everything is constexpr - zero-overhead in optimized builds - requires at least C++11, uses newer features if available From the Boost.Flags documentation: > Why do we use the bits of integer types for Boolean options? > > - easy to define, e.g. as macros, integer constants or enumerators > - language support for setting and querying through bitwise operators > - compact representation in memory > - simple bulk transfer in interfaces (on many platforms an int can > hold up to 32 different Boolean options) > - enforces the usage of names, especially to prevent bool parameters > in interfaces: > - "Boolean arguments loudly declare that the function does more than > one thing. They are confusing and should be eliminated." [C. Martin, > Clean Code] But C++ already has everything to work with integer-based flags, so why do we need Boost.Flags? The answer is type-safety! With integer-based flags we can do too much. E.g. when there are multiple different integer-based flag sets, nothing prevents the programmer from accidentally mixing flags from unrelated flag-sets. And of course, there are problems with the bitwise negation operator~. If you want to know, what possibly could go wrong, read the docs. The Github page: https://github.com/tobias-loew/flags The online docs: https://tobias-loew.github.io/flags Example on Godbolt: https://godbolt.org/z/qbojncnd7 I am looking forward to your comments! Tobias

5 11

Re: [boost] Boost C++ in Australia
by Hans Dembinski 05 Apr '24

05 Apr '24

> [...] you're supposed to refer to these as "megameters" As an educated physicist, I concur (*). Also, it's time that the general public finally uses kilo-, mega-, and gigadollars, to avoid the confusion what a "billion" means in different languages https://en.wikipedia.org/wiki/Long_and_short_scales#Current_usage (*) Actually, not even physicists use megameters for some reason, neither does anyone say megagrams... people are so inconsistent.

3 2

Reminder: The master branch closes for the 1.85.0 release TOMORROW
by Marshall Clow 02 Apr '24

02 Apr '24

Calendar: https://www.boost.org/development/ — Marshall

1 0

Re: [boost] Technical Excellence?
by Peter Dimov 02 Apr '24

02 Apr '24

Ivan Matek wrote: > If there is some boost contributing for dummies so that I don't waste more > time in PR review for maintainers than I saved for them by renaming 8 uses of > boost::array to std::array I would be happy to pick some tasks next weekend. Unfortunately the procedure for bringing a library up to date with C++11 is pretty convoluted in general; it's only easy if the library is actively maintained and has up to date CI, and even then, dependency changes require updating the CMakeLists.txt file. For an "old" library, what I generally do is 1. Update (or add) Github Actions CI 2. Fix any test failures that the above has exposed (this happens surprisingly often and is sometimes not easy) 3. If the library has C++11 dependencies and therefore already requires C++11, update meta/libraries.json with the 11 requirement and drop 03 from CI (if not, add a BOOST_PRAGMA_MESSAGE that C++03 will be dropped two releases from now) 4. Add CMake jobs to CI. This requires adding test/CMakeLists.txt and supporting files. 5. Finally, change boost::array to std::array and remove the include of <boost/array.hpp> 6. Regenerate CMakeLists.txt using `boostdep --cmake libname`, if it was generated, or update it manually, if not, to drop Boost::array 7. See if anything broke on CI, and fix it which... isn't generally something a new contributor can do on his own.

1 0

A few updates...
by David Sankel 02 Apr '24

02 Apr '24

Hi all, I have a few updates regarding Boost organization that I wanted to share with the wider community. First, as many of you are already aware, Vinnie Falco, Rene Rivera, and others from the C++ Alliance have set up a rival Boost website (boost.io vs. boost.org) Boost Twitter account (@BoostLibraries vs. @Boost_Libraries), and LinkedIn account. As this behavior is gravely injurious to the Boost community and amounts to a hostile takeover attempt, it has been decided to ban these individuals from the Boost mailing list for the foreseeable future. Libraries owned by these individuals will be removed from the main Boost distribution in future releases unless others volunteer to continue their maintenance. Additionally, we have initiated legal action to get these false Internet assets taken down under common trademark law. I hope with these steps we will finally put behind us the unfortunate events of the past few months. Second, we have decided to retire the Boost mailing list in favor of discord.boost.org to attract a newer demographic of Boost users and developers who prefer this medium to legacy mailing lists. The transition will not be immediate, but we hope to have it complete by April 1, 2025. I know some of you have been reluctant to this kind of change, but as Roy T Bennett once said, "change begins at the end of your comfort zone." Third, I am very pleased to announce that Microsoft has given the Boost Foundation a $850,000 grant as part of their Rust initiative. These funds will be used primarily to port Boost libraries to the Rust programming language. We will begin by porting recent additions to Boost, such as Boost.Parser, since some of the older libraries (e.g. Boost.SmartPtr) already have equivalents in the Rust standard library. The Boost community is invited to provide additional input as to the priority of various conversions. Finally, and with some regret, I must share the news that the Boost Foundation will be dissolving itself per popular request from Boost developers considering it (incorrectly) be concerned with only the C++Now conference. The Boost Foundation's assets will be held under trust by Robert Ramey and Niall Douglas until more appropriate governance is built. That's all for now. I hope y'all have a great week! -- David Sankel

7 7