April 2024 - Boost - lists.preview.boost.org

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

13 Aug '24

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

49 199

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

09 Aug '24

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

10 9

Paul Bristow
by John Maddock 08 Aug '24

08 Aug '24

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

6 5

boost::any_cast gives build errors with VS2022, boost v1.82 and C++17
by Bhuyan, Jyotideep 01 Jul '24

01 Jul '24

Hi, I was using VS2019, boost v1.78, and C++14 version and the below code was working well. Same code gives build error with VS2022, boost v1.82, and C++17 due to "o << *boost::any_cast<T>(&a); " Instruction. I wanted to know why it behaves differently. Code : class any_out { struct streamer { virtual void print(std::ostream& o, const boost::any& a) = 0; virtual streamer* clone() = 0; virtual ~streamer() {} }; public: any_out() : m_streamer(nullptr) { } ~any_out() { delete m_streamer; } template <typename T> any_out(const T& value) : m_streamer(new streamer_imp<T>), m_object(value) { } any_out(const any_out& a) : m_streamer(a.m_streamer ? a.m_streamer->clone() : nullptr), m_object(a.m_object) { } template <typename T> any_out& operator=(const T& r) { any_out(r).swap(*this); return *this; } any_out& operator=(const any_out& r) { any_out(r).swap(*this); return *this; } any_out& swap(any_out& r) noexcept { std::swap(m_streamer, r.m_streamer); std::swap(m_object, r.m_object); return *this; } friend std::ostream& operator<<(std::ostream& o, const any_out& a) { if(a.m_streamer) { a.m_streamer->print(o, a.m_object); } return o; } boost::any& get() { return m_object; } const boost::any get()const { return m_object; } bool empty() const { return m_object.empty(); } private: template <typename T> struct streamer_imp : public streamer { virtual void print(std::ostream& o, const boost::any& a) { try { if (a.empty()) { o << "<empty>"; } else { o << *boost::any_cast<T>(&a); } } } virtual streamer* clone() { return new streamer_imp<T>(); } }; // Members streamer* m_streamer; boost::any m_object; }; I have migrated to VS2022, boost v1.82, and C++17, and due to a build error, I have changed the code below. virtual void print(std::ostream& o, const boost::any& a) { try { if (a.empty()) { o << "<empty>"; } else { o << boost::any_cast<T*>(a); } } } any_out anyTest; anyTest = 100; std::string actualStr; actualStr = make_string() << anyTest; actualStr prints nullptr (0000000) instated of value 100 for VS2022, boost v1.82 and C++17 Best Regards, Jyotideep (JD) 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. Confidential - Company Proprietary

3 3

[release] Boost 1.85.0
by Marshall Clow 28 May '24

28 May '24

Release 1.85.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 two new libraries: * Boost.Charconv: A high quality implementation of <charconv> in C++11, from Matt Borland. * Boost.Scope: A collection of scope guard utilities and a unique_resource wrapper, from Andrey Semashev. The release also contains numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.85.0> You can also download directly from: <https://boostorg.jfrog.io/artifactory/main/release/1.85.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

6 25

modern logic classes
by g.peterhoff＠t-online.de 18 May '24

18 May '24

Hello, I would like to provide modern logic classes, please see https://github.com/boostorg/logic/issues/30 What are your opinions/comments on this? thx Gero

8 15

GSOC '24 at Boost
by David Bellot 05 May '24

05 May '24

Hi all, Another year, another GSOC's coming! As you all know now, Inbal is in charge of managing our GSOC program at Boost. Over the past years, I had the pleasure to work with many of you and we had the chance to have many great students and mentors. This year, however, it seems we don't have enough mentors yet. I know it's just the beginning of the year, but I would like to encourage you to join this program as a mentor, and help students to participate in Boost and become great C++ developers. It's a very rewarding journey I took myself years ago and you will learn so much, both on the technical and human side. If you want to become a mentor, just add your name to this shared spreadsheet: https://docs.google.com/spreadsheets/d/1_eUWRsXnhi_JwKZbHZsGQf3WNUESsAPE4lV… Cheers, David

4 3

Proposal for yet another MQTT library for Boost
by Takatoshi Kondo 01 May '24

01 May '24

Dear Boost Developers, I'd like to propose a MQTT library to the Boost Libraries. Repository link: https://github.com/redboltz/async_mqtt Document link: https://redboltz.github.io/async_mqtt/doc/5.0.0/index.html Here is characteristics of async_mqtt: - C++17 or later is required. - async_mqtt supports Boost.Asio style completion tokens. - e.g. use_future, deferred, use_awaitable, callback functions, etc - Not only MQTT client but also MQTT server is supported. - User can use this library to develop MQTT broker. - Sample MQTT broker application is included. - Both MQTT v3.1.1 and v5.0 are supported. - In addition, undetermined protocol version is supported for server implementation. In this case, the protocol version is decided when you receive CONNECT packet. - Continuous packet sending - Users can send the next MQTT packets before the previous sending is not completed (completion handler is not invoked yet). - Auto acquiring/mapping topic alias is supported. - In addition, when resending a PUBLISH packet after reconnecting, the topic alias is removed and the original topic is restored. It is required by MQTT v5.0 spec. - Packet based send()/recv() APIs. - MQTT has various packets and some of their fields are optional. In order to keep simple APIs, async_mqtt uses packet based APIs. - See https://redboltz.github.io/async_mqtt/doc/5.0.0/tutorial/send_recv.html - Layered archtecture - async_mqtt can have predefined TCP, TLS, WS, WSS, and user defined underlying layer. Users can access the underlying layer using next_layer() member function of MQTT endpoint. So you can configure any layers by yourself. e.g. tcp_no_delay, set send/recv buffer size, etc - See https://redboltz.github.io/async_mqtt/doc/5.0.0/tutorial/create_endpoint.ht… - High performance - See https://redboltz.github.io/async_mqtt/doc/5.0.0/performance.html Background I have developed another mqtt library mqtt_cpp https://github.com/redboltz/mqtt_cpp since 2015. It is widely used but has some limitations. For example: - The functions are directly mapped to packets(publish, subscribe, etc), so optional features are not designed cleanly. - Due to set_publish_hander / on_publish style handler design, Completion Token cannot be supported. Based on this 9years experience, I designed the new MQTT library. This is async_mqtt. I would appreciate if you could endorse this library. Regards, Takatoshi Kondo

3 4

Re: [boost] modern logic classes
by g.peterhoff＠t-online.de 29 Apr '24

29 Apr '24

Here is an update. Since a few boost libraries use tribool, these would have to be converted to bool3. Unfortunately it is not that easy to establish a new boost library. Especially if it is incompatible with previous implementations. thx Gero

1 0

Can we get rid of auto-linking?
by René Ferdinand Rivera Morell 29 Apr '24

29 Apr '24

Today I got bit by auto-linking again. As I forgot to define BOOST_ALL_NO_LIB in a CI build. I can't remember a time when auto-linking has been beneficial. And I've lost the number of times I've had to answer user questions with "Auto-linking is getting in the way. Define BOOST_ALL_NO_LIB and link normally." more times than I can count. If there was ever a benefit to auto-linking it has not surpassed the drawbacks. So.. Can we get rid of auto-linking? -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supone Nada -- Robot Dreams - http://robot-dreams.net

7 15

Emitting complete type information in boost-python docstrings
by Jakob van Santen 29 Apr '24

29 Apr '24

Hello, I’m not sure if this is the right forum for this question, but here goes: I work on a large scientific codebase that is heavily tied to boost, and that most users interact with via boost-python. Lately I have been working on generating PEP 484 type stubs for the ~1000 classes it exposes in order to enable static type checking and code completion in editors. This required some modifications to boost-python itself in order to get complete type information into the generated docstrings, where it can be consumed by external tooling to generate stubs: https://github.com/boostorg/python/pull/417 I have found this quite useful, and suspect it might be useful for others as well to have it in a Boost release. Can anyone give me a pointer as to how to make that happen, or let me know where or whom I should be asking instead? I asked on cplusplus-sig(a)python.org <mailto:cplusplus-sig@python.org>, which was the place many years ago, but that list seems to have died out. Many thanks in advance! Cheers, Jakob ------------------------------------------------------- Jakob van Santen DESY - Deutsches Elektronen-Synchrotron Platanenallee 6, D-15738, Zeuthen Office 2L/32 +49 (0)33762-7-7233 -------------------------------------------------------

2 1

BOOST_THREAD_HAS_EINTR_BUG...
by David Bien 26 Apr '24

26 Apr '24

Not really sure where to bring this issue up. I have a singleton globals object with a session manager, share manager, etc. that is destroyed atexit() on final reference release. There are a few mutexes in the implementation. This functions fine on Windows, MacOS, etc - the globals object is released during atexit() and shutdown proceeds normally. Under Linux when BOOST_THREAD_HAS_EINTR_BUG is defined we SIGABRT at this: ~mutex() { BOOST_VERIFY(!posix::pthread_mutex_destroy(&m)); } The verify fails and we abort(). When I define BOOST_THREAD_HAS_NO_EINTR_BUG we do not abort - which means that posix::pthread_mutex_destroy() returns 0 in the case where BOOST_THREAD_HAS_NO_EINTR_BUG is defined and returns non-zero in the case of it not being defined. Guidance? Also point me at a better place for this discussion if there is such a place. Thanks, David Bien

3 10

question about singleton_pool
by 李重斌 26 Apr '24

26 Apr '24

I want to use singleton_pool to manage memory. This is just an example which tests it. My question: the first time i allocate 100 spot object, and free them. If i allocate some spot objects, and the number of them is less than 100. no more memory is needed, there is no need to allocate memory from os again. but the fact is another memory block is allocated. The first block is 4016 bytes (sizeof(Spot) = 40), the second block is 8016 bytes. This is not as my imagine. Is there something wrong with these code? ///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// std::cout << "size of Spot " << sizeof(Spot) << " bytes\n"; std::cout << "test singleton_pool firt time\n"; const size_t NumSpots = 100; Spot* p1 = static_cast<Spot*>(spot_pool::ordered_malloc(NumSpots)); for (size_t i = 0; i < NumSpots; i++) { p1[i].x = 1; p1[i].y = 1; } spot_pool::ordered_free(p1); std::cout << "test singleton_pool second time\n"; Spot* p2 = static_cast<Spot*>(spot_pool::ordered_malloc(NumSpots/2)); for (size_t i = 0; i < NumSpots/2; i++) { p2[i].x = 2; p2[i].y = 2; } spot_pool::ordered_free(p2); /////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

1 0

UUID design discussion
by Peter Dimov 26 Apr '24

26 Apr '24

We've been discussing some UUID design issues in, well, issues in the Uuid repo, namely https://github.com/boostorg/uuid/issues/96 and, for context, https://github.com/boostorg/uuid/issues/113. This topic might be of wide interest to developers, so I thought it would be better to have this list know about it. Anyone who has an opinion on the matter is welcome to express it in the issue, or here. In addition to the questions raised in #96, namely, how should the constructors and the accessors of `uuid` look like (once we somehow move away from the public `data` member), here are some more topics of interest: * Should a default-constructed `uuid` remain uninitialized, or should the default constructor produce the nil Uuid? (Uninitialized is not a good look in 2024 because safety. On the other hand, `new uuid[ 1048576 ]` will start doing a `memset`.) * At the moment wide strings are processed by the name generators by converting every wchar_t to 32 bit, then hashing the bytes, zeroes and all. This doesn't strike me as correct. I think that the string should be converted to UTF-8 on the fly (with 32 bit wchar_t assumed UTF-16 and 32 bit wchar_t assumed UTF-32.)

5 11

Re: [boost] modern logic classes
by g.peterhoff＠t-online.de 25 Apr '24

25 Apr '24

>> Hello, >> I would like to provide modern logic classes, please see https://github.com/boostorg/logic/issues/30 >> What are your opinions/comments on this? > Interesting idea. > But rather than messing with tribool, I'd prefer to just see a new library quadbool. I would also like tribool to be removed. But until then it still needs to be supported. regards Gero

1 0

[stacktrace] boost_stacktrace_from_exception on non-x86
by Tim Haines 24 Apr '24

24 Apr '24

This feature is guarded by BOOST_STACKTRACE_ALWAYS_STORE_IN_PADDING, but that is only enabled on x86 ( https://github.com/boostorg/stacktrace/blob/a33e198cf660c213e700d6f050a4641…) This means that ./bootstrap.sh --with-toolset=gcc --with-libraries=stacktrace ./b2 install threading=multi toolset=gcc always fails to build on non-x86 platforms. There are three current workarounds: 1) set boost.stacktrace.from_exception=off 2) set BOOST_STACKTRACE_LIBCXX_RUNTIME_MAY_CAUSE_MEMORY_LEAK 3) build with threading=single (1) prevents me from using this feature. (2) shouldn't be needed on it's face because I'm using gcc/libstdc++. (3) affects more than stacktrace. Is this an incidental error, or is there a reason I wasn't able to deduce as to why this feature can't be used on non-x86+libstdc++? It seems like the check for libc++ on non-x86 can't be entirely done at compile time. I definitely understand wanting to alert users to the dangers of using this feature, but there also doesn't seem to be a good way of detecting the presence of libc++ at compile time (hence the need for https://github.com/boostorg/stacktrace/blob/a33e198cf660c213e700d6f050a4641… ). Thanks. - Tim

1 0

Boost board update on website, twitter, etc.
by David Sankel 21 Apr '24

21 Apr '24

Hi all, We're overdue for a Boost website/Twitter status update as it relates to the board. In summary: - The board approved pointing boost.org to C++ Alliance servers running the new website once it's ready - The board is accepting a contribution from the C++ Alliance to upgrade the @Boost_Libraries Twitter account to premium, which simplifies delegation of credentials for posts - The C++ Alliance made their @BoostLibraries Twitter account private which means only its subscribers will see its posts. The website decision was made in the 3/28 board meeting which followed the 3/13 meeting where several on boost-dev were invited to the discussion. You can read the minutes here <https://docs.google.com/document/d/1zMKUX3nfdcOXT6nUIU4M_YRlCU4ywGoG40ouo3I…> . The website decision was not easy. There wasn't consensus in boost-dev nor on the board itself (it passed with 3 in favor, 2 against, and 1 abstention). However, a needed decision was made and I invite everyone to rally behind it and support its success. I want to thank Vinnie and those working for the C++ Alliance for their major Boost website contributions. I want to acknowledge the reviewers, active Boost authors, review managers, folks making releases, bug reporters, infrastructure maintainers, and the many others that contribute to Boost in various ways. These people constitute the Boost libraries project whose consensus is the primary means of community-wide decision making. The Boost Steering Committee (and now the Boost Foundation) was created by the Boost libraries project to make such decisions *only in the rare case of community deadlock*. While the Boost board is more than happy to provide feedback and financial support for Boost libraries initiatives, the board is taking its direction from the project and not the other way around. Thanks everyone for your passionate interest in Boost and I look forward to what comes next! David, Boost Foundation Chair

2 1

On Boost and modules: second part
by Ruben Perez 19 Apr '24

19 Apr '24

Hi all, Following the recent discussion on Boost and C++20 modules, I've been performing further investigations on the possible benefits and costs of offering module support in Boost. I've summarized my findings here: https://anarthal.github.io/cppblog/modules2 TL;DR: * While there isn't too much benefit for clean builds, incremental builds tend to be much faster with modules. * Right now, modularizing requires an effort for each modularized library. * Writing CMake files for module consumption won't be trivial. I'd like to know everyone's opinion on this: do you think these efforts would make sense? In the mid-term, this will require authors to review and merge module-related PRs, at the very least. I'm especially interested in hearing René and Peter's opinions, as maintainers of B2, Boost.CMake and many other core parts (as well as other authors'). If the community decides these efforts may be worthwhile, I volunteer to perform most of the required work. My first step would be to create a working prototype with a modularized Boost.Url (as a maintained, separately compiled library, with non-trivial dependencies), together with CMake tooling, to spot any pitfalls I've missed during my analysis. I'd also like to drag any present MSVC developers' attention on this bug which has nasty consequences on code like Asio: https://developercommunity.visualstudio.com/t/Using-%5f%5ftry-in-an-inline-… Thanks, Ruben.

4 4

[release] Boost 1.85.0 Release Candidate 3 is available
by Marshall Clow 18 Apr '24

18 Apr '24

The third 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: e712fe7eb1b9ec37ac25102525412fb4d74e638996443944025791f48f29408a boost_1_85_0_rc3.zip 7009fe1faa1697476bdc7027703a2badb84e849b7b0baad5086b087b971f8617 boost_1_85_0_rc3.tar.bz2 16d16b9658753117c1434e5450c5eac194957f4b6d0b390b9d07900d37c115a4 boost_1_85_0_rc3.7z be0d91732d5b0cc6fbb275c7939974457e79b54d6f07ce2e3dfdd68bef883b0b boost_1_85_0_rc3.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. * A meaningless change to Boost.Array (add a space to a test file) Apparently the RC2 tarballs were mis-buiilt; some of them were missing the required changes. I believe that RC3 resolves that problem. 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 25

A base64 library?
by Ruben Perez 17 Apr '24

17 Apr '24

Hi all, I've been thinking of writing a base64 encoder/decoder library for some time. I first found the need when writing ServerTech chat (https://github.com/anarthal/servertech-chat) and I couldn't find a library that suited my needs. All the libraries I could find were either forgotten one-day projects with no tests, or private parts of something bigger. >From this issue from Beast (https://github.com/boostorg/beast/issues/1710) it looks like this could be useful to people. My idea would be writing something that is: * Boost quality - extensive testing and fuzzing. * Configurable. My use case in ServerTech required me to not output padding chars, for instance. * Support for a streaming API. * Support for calling in a constexpr context. * I'd prefer to focus on doing base64 only and doing it well, rather than targeting arbitrary bases. I don't have any sample code yet. Following our recommendations, I'm only determining interest. My questions are: * Do you think a library like this could be useful to the C++ community? * If the answer to the above is yes, do you think it could belong to Boost, or would be better as a standalone library? Regards, Ruben.

13 30

Things I Hate (Re: New Website)
by Vinnie Falco 17 Apr '24

17 Apr '24

Now that we're here I want to tell you about some things I hate. To clear out any suspense they are: 1. April Fool's 2. Deadlines 3. New Boost Website April Fool's I can't stand this fauxliday and I refuse to participate. Every year sees the C++ community produce an outsized load of lame jokes. The problem, I think, is that comedy on some level has to come at someone else's expense. Good comedy at least. Our community is so damn politically correct that folks are afraid to make a really good joke for fear of getting canceled at some level. Deadlines I hate deadlines. People ask me "how long will this take" and honestly I have no idea. About a decade ago I stopped trying to estimate how long things take as I never was able to give a reasonably accurate answer. I'm good at writing the code, but figuring out how long it will take - not so much. During development, unanticipated stuff comes up. A discovered design flaw or implementation obstacle, which can't be predicted. These days I just figure that if a project is properly staffed and there is reasonable daily progress, eventually it will get finished. New Boost Website Well I don't hate the whole thing but there is definitely stuff which is bothering me. Like how long the thing is taking. Seems like it is still not ready to go up on boost.org. But more importantly I have to be honest... I'm not feeling this Cairo font. I am just going to come out and say it: the old Quickbook stylesheets are superior to the new stylesheets which render in Cairo. Compare: https://www.boost.org/doc/libs/1_85_0/libs/beast/doc/html/beast/ref/boost__… vs. https://www.boost.io/doc/libs/1_84_0/libs/beast/doc/html/beast/ref/boost__b… or https://www.boost.org/doc/libs/1_85_0/libs/beast/doc/html/beast/concepts/Dy… vs. https://www.boost.io/doc/libs/1_84_0/libs/beast/doc/html/beast/concepts/Dyn… The new one is better than it was a month ago, thanks to Julio our new frontend developer. But it is still not as good as the old one. I cannot in good conscience propose replacing something old with something new unless the new thing is demonstrably superior. Or at the very least, equally as good. So I think we still have work to do. Thanks

4 7

[release] The master branch is now open for all changes
by Marshall Clow 16 Apr '24

16 Apr '24

Next deadline: June 26th - Boost 1.86.0 closed for new libraries and breaking changes` As always, the calendar is at: https://www.boost.org/development/ — Marshall

1 0

Boost.Graph security issues
by Jeremy Murphy 13 Apr '24

13 Apr '24

Dear Boost community, I've recently received a few security issue notifications from both the Google Chrome fuzzer project and Shielder (part of an OSTIF project), and basically I'm not sure how much to worry about them. I don't have time to fix them (but I can review and merge fixes), and I don't know how to draw attention to the need to fix them without publicizing the issues (which are still not published). It all depends on how many people actually are exposed via Boost.Graph and to what severity, right? I have no idea, but my gut tells me not many, as most Boost.Graph users I hear about are just using it internally, not exposing the interfaces to input from the Internet. But I'm not a security expert, that's why I'm asking you. What should I do? Thanks, cheers. Jeremy

3 5

Re: [boost] Boost C++ in Australia
by Jeremy Murphy 13 Apr '24

13 Apr '24

Hi David, Hello from Sydney, at least for the next six months. I'd love to catch up, although finding time is hard. Cheers. Jeremy On Wed, 3 Apr 2024, 8:05 am David Bellot via Boost, <boost(a)lists.boost.org> wrote: > Hi all, > > reading through the Boost mailing list, I've realized several of you live > in the country of kangaroos and cute koalas (and great white sharks and > funnel web spiders too, thinking of it). > > As I am too, why don't we find a good opportunity to gather, hoping that > we're in the same city. If it's not the case, then chances are we are > "just" a few thousands kilometers away from each other! > > Let me know what you think > > Cheers, > David > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Technical Excellence?
by Vinnie Falco 12 Apr '24

12 Apr '24

I guess I'm confused. My understanding is that libraries are considered good candidates for the Boost collection based on meeting some or all of certain criteria: * They offer useful, novel functionality not found elsewhere * The API is superior to other libraries that do similar things * The implementation is exceptionally performant * Solving a familiar problem in a particularly elegant fashion * The library is already popular and has field experience * The library offers C++ standard functionality for older compilers But some of the chatter on the mailing list suggests that the bar for a Boost library candidate is lower. That a library just needs to basically work, even if it duplicates functionality found elsewhere, or even if it does not have anything that one might hold up as an example of exceptional engineering. Boost libraries used to be cutting edge, to such an extent that they were adopted into the C++ Standard. And now the progress is in reverse. The Standard introduces a new component, and the Boost library follows (Boost.Charconv for example). In other cases I see libraries with few to no users limping into reviews, or absent discussions which question whether or not the bar for excellence is exceeded. When I used to participate in wg21 I complained about the "direct to standard" pipeline, where people would just write papers for the sake of it with no example code or real-world user experience. I have to wonder if we are not cultivating a "direct to Boost" pipeline by having relaxed or poorly-defined acceptance criteria. There are thousands of open-source libraries for doing things in a fashion that is "good enough." If libraries are not held to technical excellence and high standards during the review process then what is the value proposition of the collection? If libraries of average design and implementation are seen as passable for acceptance then how would this inspire any authors to strive for excellence? When I write a library there are always two factors in my mind: 1. that the use-case is compelling, and 2. that I can bring something to the table which demonstrates technical excellence. These are the libraries that I have contributed thus far and my process for designing them: 1. Boost.Beast This offers something never seen before which is a generic approach to HTTP and Websocket, based on Asio, which offers models and algorithms that are designed well (of course, it still has its flaws). The library already had many users ahead of the review, and was being used to transact economic value in a live product. I will note that my initial motivation for Beast was because the websocketpp library API was just terrible, and the alternatives even worse. 2. Boost.JSON When I needed JSON I looked at the alternatives and while RapidJSON was clearly the best in terms of performance I felt that it made several major design flaws in its API. Boost.JSON pretty much copies all of the good ideas from RapidJSON especially the performant implementation, and offers a redesigned API that follows C++ best practices with respect to copy and move, exceptions, and error codes. Furthermore I added the streaming parser and I introduced a novel means of managing memory resources which I believe corrects a design flaw in the standard. This library already had commercial users and lots of feedback before going into review. 3. Boost.URL Beast users regularly asked for URL parsing. There are some regex patterns floating around and some Spirit based parsers, and also some URL libraries that do the "five std::string data members" thing. I wanted something excellent, but the first two iterations of an API turned out to be crap and I gave up, as I do not like publishing mediocre libraries. Some time passed and with renewed energy I tried again and then I got it right. The URL is stored in its serialized form (just one string), allowing the possibility for having a url_view type in addition to the mutable container. I copied much of the API from a popular JS URL lib because, well hey why duplicate the effort if someone has already gone through the trouble :) Boost.URL offers particularly clean and robust interfaces for reading and modifying the values of each part of the URL both with and without the URL-encoding applied. The mechanism for lazily iterating the path and query sequences is novel. And it offers a strong invariant: the container will always contain a valid URL. The library further innovates by making public its parsing framework which is optimized for the type of grammars found in the Internet RFCs such as HTTP and the fields used in Websocket handshakes. Boost.URL had a bunch of users before the review was conducted. 4. Boost.StaticString This one is just a straightforward string container whose storage is fixed in capacity as a data member. Container libraries are often unexciting but they are necessary. StaticString follows all best practices for modern C++ containers. When I look at a proposed library I try to figure out what is great about it, how well it performs for its users (or even, does it have any users?), what part of the API is exceptionally well designed and ergonomic, but most importantly I want to ask: what makes this library stand out to the extent that it should be part of the library collection? What aspects of the library, if viewed by someone learning C++ or interested in improving their design skills, are inspirational? Is this overly demanding or exclusionary? Am I overthinking things? Should we be asking more of these types of questions and requiring better answers? What is the criteria for determining if a library is good enough to become part of the collection? Thanks

26 78

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

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

[release] Master branch is now open for bug fixes
by Marshall Clow 01 Apr '24

01 Apr '24

The master branch is now open for bug fixes, test 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 April 3rd, master closes for all changes. As always, the calendar is at https://www.boost.org/development/ — Marshall

12 22