- Boost - lists.boost.org

On Boost and modules
by Ruben Perez 12 Apr '24

12 Apr '24

Hi all, Following a recent conversation on the possibility to somehow enable Boost to be consumed using C++20 modules, I've jumped in and done a small research: https://anarthal.github.io/cppblog/modules René posted the link to r/cpp and it seems to have attracted some interest (https://www.reddit.com/r/cpp/comments/1bxggim/c20_modules_and_boost_an_anal…) It looks like a small fraction of users would consider consuming Boost as modules if there was the possibility (note that considering here is pretty far from actually doing it). Nevertheless, I'd like to know everyone's opinion on the subject. If we find a way to overcome the technical challenges that I manifest in the article, do you think a set of non-intrusive "module bindings" allowing users to consume Boost as a module could add any value to Boost? Thanks, Ruben.

14 62

Re: [boost] [release] Boost 1.85.0 Release Candidate 2 is available
by Glen Fernandes 11 Apr '24

11 Apr '24

I wrote: > I think we saw this before, but I couldn't figure it out: > https://github.com/boostorg/boost/issues/884 Many thanks to Sam Darwin for finding the cause (and looking into a long term solution in the new website release mechanism). Glen

1 0

[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