June 2022 - Boost - lists.boost.org

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

13 Aug '24

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

49 200

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

10 Aug '24

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

10 10

Library proposal - indexed_array
by Julien Blanc 12 Oct '23

12 Oct '23

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

8 24

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

Boost.URL review planned for 13-22 August 2022
by Mateusz Loskot 22 Aug '22

22 Aug '22

Folks, Klemens Morgenstern kindly volunteered [1] as the Review Manager (thanks Klemens!) for the Boost.URL [2], so we have planned the review shortly after the upcoming release of the Boost 1.80. Check the Review Schedule [3] for details! [1] https://lists.boost.org/Archives/boost/2022/06/253225.php [2] https://lists.boost.org/Archives/boost/2022/04/252814.php [3] https://www.boost.org/community/review_schedule.html Best regards, -- The Boost Review Wizards Mateusz Loskot

3 4

[review][JSON] Review of JSON starts today: Sept 14 - Sept 23
by Pranam Lashkari 09 Aug '22

09 Aug '22

Boost formal review of Vinnie Falco and Krystian Stasiowski's library JSON starts today and will run for 10 days ending on 23 Sept 2020. Both of these authors have already developed a couple of libraries which are accepted in Boost(boost beast and Static String) This library focuses on a common and popular use-case for JSON. It provides a container to hold parsed and serialised JSON types. It provides more flexibility and better benchmark performance than its competitors. JSON highlights the following features in the documentation: - Fast compilation - Require only C++11 - Fast streaming parser and serializer - Easy and safe API with allocator support - Constant-time key lookup for objects - Options to allow non-standard JSON - Compile without Boost, define BOOST_JSON_STANDALONE - Optional header-only, without linking to a library (a point I would like to add in highlight: it has cool Jason logo 😝) To quickly understand and get the flavour of the library take a look at "Quick Look" <http://master.json.cpp.al/json/usage/quick_look.html> You can find the source code to be reviewed here: <https://github.com/CPPAlliance/json/tree/master> You can find the latest documentation here: <http://master.json.cpp.al/> Benchmarks are also given in the document which can be found here: <http://master.json.cpp.al/json/benchmarks.html> Some people have also given the early reviews, the thread can be found here: <https://lists.boost.org/Archives/boost/2020/09/249745.php> Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including JSON as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found here: <http://www.boost.org/community/reviews.html> Thank you for your effort in the Boost community. -- Thank you, Pranam Lashkari, https://lpranam.github.io/

21 73

Boost 1.80 closed for all major changes
by Glen Fernandes 05 Jul '22

05 Jul '22

The next deadlines: - On 2022-07-06 master is closed for all changes. - On 2022-07-13 the beta is published -- Release Managers

3 6

Re: [boost] [Boost-users] Boost.URL review planned for 13-22 August 2022
by Vinnie Falco 29 Jun '22

29 Jun '22

On Fri, Jun 24, 2022 at 2:15 AM Mateusz Loskot via Boost-users <boost-users(a)lists.boost.org> wrote: > we have planned the review shortly after the upcoming release of the Boost 1.80. The review starts in August but there is no rule that says folks can't look at the library sooner :) The library is in very good shape and likely usable for your project today (although we do expect bugs to be found, which will be fixed as they get reported). Check it out here: <https://github.com/CPPAlliance/url> Docs: <https://master.url.cpp.al/> We're glad to answer any questions at any time either on the list or feel free to open an issue in the repository (even if it is just a question). Thanks

2 1

Boost Regression Results Not Updating
by Tom Kent 25 Jun '22

25 Jun '22

I just noticed that something happened with the regression results and they haven't updated since last Friday. https://www.boost.org/development/tests/master/developer/summary.html https://www.boost.org/development/tests/develop/developer/summary.html I'm not sure where these run these days, would it fit in a github action on the regression repo? Tom

3 3

Possible develop config issue on arm32
by Tom Kent 25 Jun '22

25 Jun '22

I have a regression runner running on raspberry pi 32-bit architecture (in addition to a one on 64-bit raspberry pi and tons of X86). gcc-8 builds fine in both master and develop clang-9 builds fine on master clang-9 running the same command line, just on develop, has errors like this [1], finding basic includes: ``` "clang++-9" -c -x c++ -Wno-c99-extensions -std=c++2a -O0 -fno-inline -Wall -g --target=arm-pc-linux -Wno-deprecated-declarations -DBOOST_ALL_NO_LIB=1 -DBOOST_BEAST_ALLOW_DEPRECATED -DBOOST_BEAST_SEPARATE_COMPILATION -DBOOST_TEST_NO_AUTO_LINK=1 -I".." -o "/mnt/fs1/teeks99-05/run/results/boost/bin.v2/libs/accumulators/test/count.test/clang-linux-9~c++2a/debug/link-static/count.o" "../libs/accumulators/test/count.cpp" clang: warning: unknown platform, assuming -mfloat-abi=soft clang: warning: unknown platform, assuming -mfloat-abi=soft In file included from ../libs/accumulators/test/count.cpp:6: In file included from ../boost/test/unit_test.hpp:18: In file included from ../boost/test/test_tools.hpp:17: In file included from ../boost/config.hpp:44: ../boost/config/detail/select_stdlib_config.hpp:26:14: fatal error: 'cstddef' file not found # include <cstddef> ^~~~~~~~~ 1 error generated. ``` The relevant line of the user-config.jam is: using clang : 9~c++2a : clang++-9 : <cxxflags>"-Wno-c99-extensions -std=c++2a" ; The two command lines being run are: run.py --runner=teeks99-05-mc9-2a-32onarmv7l --toolsets=clang-9~c++2a \ "--bjam-options=-j4 address-model=32 --remove-test-targets" \ --comment=info.html --tag=master run.py --runner=teeks99-05-dc9-2a-32onarmv7l --toolsets=clang-9~c++2a \ "--bjam-options=-j4 address-model=32 --remove-test-targets" \ --comment=info.html --tag=develop Any ideas why master and develop would be different in this regard? Something with B2 changes? Thanks, Tom [1] https://www.boost.org/development/tests/develop/developer/output/teeks99-05…

3 2

Boost.URL review
by Klemens Morgenstern 24 Jun '22

24 Jun '22

Hi guys, I would like to volunteer as review manager for boost.url. Who can guide me through the process? Best regards, Klemens

2 2

Boost 1.80 closed for new libraries and breaking changes
by Glen Fernandes 23 Jun '22

23 Jun '22

Next deadline: On 2022-06-29 closed for all major code changes. See https://www.boost.org/development/index.html for the full calendar. -- Release Managers

1 0

Delayed response for sleep function
by Daggumati, Rajesh 22 Jun '22

22 Jun '22

Hi Team, When I use boost sleep function, I am getting delayed response. How to overcome this issue. Is there any alternative for this? boost::posix_time::ptime t1 = boost::posix_time::microsec_clock::local_time(); boost::this_thread::sleep(boost::posix_time::millisec(10000)); boost::posix_time::ptime t2 = boost::posix_time::microsec_clock::local_time(); boost::this_thread::sleep(boost::posix_time::millisec(10000)); boost::posix_time::ptime t3 = boost::posix_time::microsec_clock::local_time(); boost::posix_time::time_duration diff = t2 - t1; std::cout << diff.total_milliseconds() << std::endl; boost::posix_time::time_duration diff1 = t3 - t2; std::cout << diff1.total_milliseconds() << std::endl; output is : 10005 10006 Expected ouput should be 10000 and 10000 Regards, Rajesh D 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.

6 8

Re: [boost] Delayed response for sleep function
by William Linkmeyer 22 Jun '22

22 Jun '22

This is interesting and helpful — yes! Although, it sounds like it’s more pertinent to software timers, right? I’ve done some work with hardware RTCs, many of which drift by 4ms/day, others by a few ms/year. (For physical quartz clocks, drift is a function of temperature and crystal frequency.) I had assumed that these clocks were more-or-less ubiquitous on computers today. Anyway, best regards and thank you for your detailed response. WL > On Jun 21, 2022, at 4:12 AM, Neil Groves <neilgroves(a)gmail.com> wrote: >

2 2

Re: [boost] [Boost-users] Boost Twitter is Blowing Up!!!
by Vinnie Falco 21 Jun '22

21 Jun '22

On Mon, Jun 20, 2022 at 7:48 PM 😉 Good Guy 😉 via Boost-users <boost-users(a)lists.boost.org> wrote: > The problem with Twitter is that it requires an account to read the posts. Yeah, so... my assumption when I made this post is that most folks have a Twitter account. I see that is not the case, even for long-time Boost authors. If you don't already have a Twitter account, there is not going to be much benefit to creating one just to like, follow, and retweet the Boost account, as you will have no followers and thus no reach. Although you might consider creating an account if you want to become more involved in C++ Twitter in general. That said, Twitter and the other socials might not be important to the senior engineers, authors, and maintainers here but collectively, Boost needs to catch up in terms of courting the younger generations of developers. We need fresh blood for library submissions, reviewers, and review managers. Our efforts on social media are aligned with this goal. Thanks

2 3

[JSON] Vote for Boost.JSON in this poll!
by Vinnie Falco 21 Jun '22

21 Jun '22

There's an online poll asking about which JSON library you use. If you use Boost.JSON consider voting for it: <https://meetingcpp.com/mcpp/survey/?q=2> Also, consider voting for it if you _don't_ use Boost.JSON, but you want to. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

1 0

Boost Twitter is Blowing Up!!!
by Vinnie Falco 21 Jun '22

21 Jun '22

Greetings fellow users, library authors, maintainers, review wizards, release wizards, and Boost Foundation Board members! As part of our ongoing effort to continue the revitalization of Boost, a handful of us have taken the reins to post about Boost on social media. We have postings on Reddit and Hacker news, blog posts about the new efforts in Boost.Unordered, and new tweets. However, we could use your help! Right now the Boost Twitter account has a measly 957 followers. It would be great to increase our reach, so I'm asking everyone if they could be so kind as to Follow the official Boost Twitter account here: <https://twitter.com/Boost_Libraries> and then amplify our messages by Liking and Retweeting. Starting with this pinned tweet, which everyone will see when they visit the Boost Libraries Twittter profile page: <https://twitter.com/Boost_Libraries/status/1539003321939202048> Following the Boost Twitter account will give you up-to-date information about what is going on with Boost, including articles and mentions on other social media sites. Here is what we have so far: <https://www.reddit.com/r/cpp/comments/vfdcrz/advancing_the_state_of_the_art…> <https://www.reddit.com/r/cpp/comments/vbdr3z/new_boostunordered_containers_…> <https://twitter.com/hackernewstop10/status/1538622706035343364> <https://news.ycombinator.com/item?id=31801814> To summarize, engaging with Boost related content on social media will enhance our profile - any help is appreciated! -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

2 1

[thread] upgrade_to_unique_lock takes a upgrade_lock, not an upgrade_mutex
by Phil Endecott 21 Jun '22

21 Jun '22

Dear Experts, boost::upgrade_mutex m; void f() { boost::upgrade_lock l(m); // read shared state g(); } void g() { // precondition: upgrade lock held. boost::upgrade_to_unique_lock l(m); // write shared state } But that's not how it works. The upgrade_to_unique_lock takes the upgrade_lock as its ctor parameter, not the mutex. Is there a good reason for that? I think all that upgrade_to_unique_lock needs to do is to call m.unlock_upgrade_and_lock() in its ctor and m.unlock_and_lock_upgrade() in its dotr, i.e. it doesn't need to access any state in the upgrade_lock. Am I missing something? Regards, Phil.

3 4

multiprecision/gmp.hpp
by Gero Peterhoff 17 Jun '22

17 Jun '22

Hello John, if i include boost::cstdint/float.hpp AND boost::multiprecision::gmp.hpp gets errors in boost::multiprecision::detail::float128_functions.hpp. With the attached patch it works, although I have no idea why this is needed. regards Gero

2 1

[Boost] [Review] [Boost.MySQL] - Review Complete
by Richard Hodges 16 Jun '22

16 Jun '22

Dear All, The submission of Boost.MySQL has created plenty of "lively debate". Unsurprisingly, a library which is based on Asio, of which there are few experts, has given rise to a great deal of questioning around performance, memory re-use, correct return types and so on. It has been noted that Reuben, the library's author, has been very responsive. Both in this mailing list and in terms of raising PRs. A specific concern was raised about the name of the library, and whether it infringed any commercial trade marks. Reuben took the trouble to reach out to Oracle to check. They have responded that there is no infringement and we may use the name. In the end though, despite a great deal of words written raising concerns, ideas and suggestions, we received size reviews, all of which were high quality. The results were: Accept: 3 Conditional Accept: 2 Reject: 1 Having carefully weighed up: - The stated aims of the library - The quality of the implementation - The demonstrated responsiveness of the author - The value of the library to users of MySQL - The value of the library as a teaching tool for implementing a complex, cancellable, asynchronous protocol on ASIO, which correctly adapts to the use of user-selection completion tokens, It seems right to ACCEPT this library into Boost. My congratulations to Reuben. -- Richard Hodges hodges.r(a)gmail.com office: +44 2032 898 513 home: +376 861 195 mobile: +376 380 212

5 5

The deadline for new libraries and breaking changes in Boost 1.80.0 is June 22
by Glen Fernandes 16 Jun '22

16 Jun '22

2022-06-22 closed for new libraries and breaking changes in Boost 1.80. See https://www.boost.org/development/index.html for the full calendar. - The Release Managers

1 0

Boost.MySQL naming
by Ruben Perez 15 Jun '22

15 Jun '22

Hi all, We have received an answer from Oracle's legal team, thanks to Norvald, who initially wrote in this ML and works for Oracle. TL;DR: Boost.MySQL keeps its name. > Naming the library as proposed (Boost.MySQL) is not a problem for a > community connector to MySQL. This is consistent with other naming we > see in the MySQL community and in our experience it has not caused > confusion. We would be concerned about any naming or statements that > suggest an inaccurate association between your library or product and > MySQL, but that does not appear to be the case. So I'm afraid we won't be having Boost.OurSQL anytime soon. Regards, Ruben.

1 0

[container] Contributing 'stationary_vector' to Boost
by Mehrdad Niknami 13 Jun '22

13 Jun '22

Hi all, Happy new year! New mailing list member here. I've developed an STL-style stationary_vector class that retains elements in-place when growing. Very briefly, it is effectively a piecewise-contiguous vector, with the following advantages over vector: - Appending has O(1) overhead in the *worst* case (e.g., push_back() does not move elements) - Insertion and random-access can be done in parallel, as prior iterators & references remain valid This has a variety of benefits, including better UX (no "hiccups" due to reallocations), and the ability to simplify parallel processing of streaming data. It occurred to me the larger C++ community might find this useful. I was wondering if there would be interest in incorporating it into Boost.Container, and if so, what steps I could take to make that happen? I'm of course happy to discuss the design etc. with anyone who might be interested. Summary: https://github.com/mehrdadn/libvital/blob/master/doc/vital/container/statio… Implementation: https://github.com/mehrdadn/libvital/blob/master/include/vital/container/st… Thank you, Mehrdad

7 19

Boost.URL -- some notes
by Andrzej Krzemienski 11 Jun '22

11 Jun '22

Hi Everyone, I am trying to do a review of Boost.URI library (I usually find the official ten-day review period to be too short), and there are a number of interesting things I came across that I thought I would mention. The docs say: > The library requires Boost and a compiler supporting at least C++11. > Even though the library is a candidate for a Boost library, I understand that it is now offered as a "stand alone" version, and this is what the docs describe. I tried to use it with the latest MinGW Distro on Windows ( https://nuwen.net/mingw.html) which uses GCC 11.2 and Boost 1.77. Without success. This is because Boost.URL relies on the component boost::system::result<T>, which is present in Boost.System only since version 1.78: https://www.boost.org/doc/libs/1_79_0/libs/system/doc/html/system.html#chan… First, this is news to me that we have `result<T>` in Boost.System, which has an overlap with result<T, E> from Boost.Outcome. Second, I recommend that Boost.URL docs say that it requires Boost 1.78 or higher. Next, we read: Aliases for standard types, such as string_view > <https://master.url.cpp.al/url/ref/boost__urls__string_view.html>, use > their Boost equivalents. > After reading this, I expected that Boost.URL would use boost::string_view from Boost.Utility library: https://www.boost.org/doc/libs/1_79_0/libs/utility/doc/html/utility/utiliti… But instead, it uses boost::core::string_view, which is an implementation detail from Boost.Core library: https://github.com/CPPAlliance/url/blob/master/include/boost/url/string_vie… Again, this is news for me that Boost has two implementations of string_view. Why? Second, I do not think that Boost.URL should rely on the implementation details of Boost.Core. A better alternative would be to use the official boost::string_view from Boost.Utility. Or is there a good reason not to? Next, the section on the parsers ( https://master.url.cpp.al/url/parsing/url.html) describes the function parse_uri() which returns result<url_view>. What strikes me is this difference: URI (Identifier) in the function name, and URL (Locator) in the return type. I always used the terms URL and URI interchangeably. But now that I see them used in this way in a well designed library, it looks disturbing. The quoted rfc3986 ( https://datatracker.ietf.org/doc/html/rfc3986#section-1.1.3) says that an URL is a subset of URI. Now, the name `parse_uri` implies that it will recognize any URI, but on the other hand it is impossible that the result will fit into a url_view, because not every URI is an URL. The synopsis for parse_uri ( https://master.url.cpp.al/url/ref/boost__urls__parse_uri.html) says: Exception safety: throws nothing. > And the line below it says that the function throws std::length_error when the input is too long. It looks like a bug in specs. Later we read: Return value: A result containing the view to the URL, or an error code if > the parsing was unsuccessful. > Which is not precise enough to give me the answer to the URI-vs-URL question. When can a parsing be non-successful? Is it only because it was not conformant to the grammar? The synopsis says "This function parses a string according to the URI grammar below", but is it a URI grammar or a URL grammar actually? Maybe the "return value" section should say instead: Return value: A result containing the view to the URL, or an error code if > the contents of `s` were not conformant with the above grammar. > That is, any other reason for not being successful (if any resources needed to be allocated and failed) may still be reported via exceptions. Now, there is probably a good explanation to the URI vs URL discrepancy. I think it would be good if it was placed in the docs, so that the users don't get confused. While this might look like a list of complaints, I really appreciate the efforts the authors put in creating this library and its documentation. The documentation is really high quality, way higher than the average you will find in GitHub. And this is actually because of this high quality that I am able to spot and report these issues. Regards, &rzej;

11 24

Any objections to making C++14 the current baseline for Boost support and testing?
by John Maddock 11 Jun '22

11 Jun '22

Pursuant of discussion elsewhere: Does anyone have any concrete objections to Boost moving to a C++14 baseline? This would mean: * Library authors can drop and remove all support for pre-C++14 compilers after a suitable deprecation notice in place for say 3 releases. * The community maintenance team can likewise drop pre-C++14 support from community maintained / orphan libaries. * CI tests no longer need report pre-C++14 results. * From the next release onward, the boost super-project should clearly announce in our release notes, that C++11 and earlier support may no longer be available from the start of 2023. Thoughts? Thanks, John Maddock.

6 8