February 2022 - 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

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

[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

[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

[release] Boost 1.7.0 beta 1 released
by Marshall Clow 13 Apr '22

13 Apr '22

Boost release 1.77.0 beta 1 is now available at: <https://boostorg.jfrog.io/artifactory/main/beta/1.78.0.beta1/source/> The SHA256 checksums are as follows: 7a3a025451dfa2923129214eef7d16b03c02310a353d02158a549f6caa4284b0 boost_1_78_0_b1.tar.bz2 c491b1dcb916195598aa6581d6708d57fcc750516641c22511c088d572de9c07 boost_1_78_0_b1.tar.gz 35e7a3b0eb412a3933e57c72ba96374eb7d88ff1f89dbec62a16d67ffea2105a boost_1_78_0_b1.7z e6b68feb2f63401c96ca9fe25e939b409189fbe526a6e784e4bd69832c8f09cb boost_1_78_0_b1.zip For details of what's in the release, see <https://www.boost.org/users/history/version_1_78_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

2 1

[Graph] Attempt to resolve open issue
by Anne van de Graaf 10 Mar '22

10 Mar '22

Hello all, I am trying to get an open issue in Boost.Graph resolved. Since I haven't received any response at the corresponding GitHub page nor from the Boost Users mailing list (where I posted the below message last Monday), I am reaching out to you. My aim is to get in touch with the maintainer(s) of Boost.Graph in order to discuss what is the preferred/most efficient way to fix the issue. Since this is my first post to this mailing list, please accept my apologies if you feel this is not the right way to get in touch with the maintainers. In that case, I would appreciate it very much if you could kindly explain what I should have done instead. Please find below a copy of my message that I sent last Monday to the Boost Users mailing list. Thank you very much for your attention and any replies. Original message: When I remove a vertex from a graph, I occasionally experience a crash (on a system running Red Hat Enterprise Linux 8.5). I have been able to replicate the behavior with the following test program: #include <vector> #include <boost/graph/adjacency_list.hpp> int main() { using MyGraph = boost::adjacency_list<boost::setS, boost::vecS, boost::undirectedS>; using MyVertexDescriptor = boost::graph_traits<MyGraph>::vertex_descriptor; using MyVertexDescriptorVec = std::vector<MyVertexDescriptor>; MyGraph g; MyVertexDescriptorVec vertices{ boost::add_vertex( g ), boost::add_vertex( g ), boost::add_vertex( g ) }; boost::add_edge( vertices[0], vertices[1], g ); boost::add_edge( vertices[1], vertices[2], g ); boost::clear_vertex( vertices[0], g ); boost::remove_vertex( vertices[0], g ); return 0; } Also on a Windows platform, I observe similar behavior. When I build the above code with Microsoft Visual Studio 2019 (MSVC 14.27.29110) and run it with a debugger, a debug assertion is triggered ("cannot increment value-initialized map/set iterator"). In both cases (on Linux and Windows platforms), the debugger reveals that the problem is at line 2071 of boost/graph/detail/adjacency_list.hpp. For clarity, I have copied the involved template function below: template < class EdgeList, class vertex_descriptor > inline void reindex_edge_list( EdgeList& el, vertex_descriptor u, boost::disallow_parallel_edge_tag) { for (typename EdgeList::iterator ei = el.begin(); ei != el.end(); ++ei) // line 2071: increment operator fails { if (ei->get_target() > u) { typename EdgeList::value_type ce = *ei; el.erase(ce); --ce.get_target(); el.insert(ce); } } } While I was searching for a proper place to post my question, I found the following issue at GitHub (which was opened on July 1 of this year): https://github.com/boostorg/graph/issues/268. This appears to be the exact same issue. So last week, I added a comment saying that I am facing the exact same problem. Unfortunately, so far no one has responded yet. To me, it seems that the problem is well-understood. Also, some have proposed a bug fix to resolve the issue (including a pull request). Nevertheless, no progress has been made over the past months. So I was just wondering what is the best way to proceed if we want to fix the issue in Boost itself? Is there anything that I can do (apart from starting this thread) to help in resolving the issue? Any feedback is greatly appreciated. Kind regards, Anne van de Graaf

3 6

std::numeric_limits<__float128>::signaling_NaN + __float128-Type
by Gero Peterhoff 26 Feb '22

26 Feb '22

Hello, please see https://godbolt.org/z/Ksshxvhaj 1) std::numeric_limits<__float128>::signaling_NaN always returns 0 but gcc-__builtin_nansq doesn't. I think __builtin_nansq is correct as it is also distinct from std::numeric_limits<__float128>::quiet_NaN (__builtin_nanq). 2) The types __float128, __extension__ __float128 (gcc) and _Quad (intel) are identical, but there are different definitions in boost/config/detail/suffix.hpp and boost/math/cstdfloat/cstdfloat_types.hpp. I think it would make sense to have just one definition or is there a reason why it was done that way? If yes, which one is it? You could always use __float128 directly and/or adjust boost/config/detail/suffix.hpp so that it also works with clang/intel. Which way would be better? I would like to help consolidate this but without having to deal with different typedef's or long #define's. thx Gero

3 13

Boost.URL Proposal
by Alan de Freitas 21 Feb '22

21 Feb '22

Hi! My name is Alan Freitas. Vinnie Falco and I are looking for a review manager for the library that we hope will become Boost.URL. I've taken over the project and in addition to introducing myself I would like to update you guys as to where we are on this in terms of progress: - Path segments can be represented as views of the underlying path - Query parameters can be represented as views of the underlying query - Percent-decoding methods return lazy constant strings with small buffer optimization and shared ownership - The library implements the specification as in RFC3986 <https://datatracker.ietf.org/doc/html/rfc3986> + its errata <https://www.rfc-editor.org/errata/rfc3986> - Non-ASCII characters are not considered valid URLs - Other specifications such as RFC3492 <https://datatracker.ietf.org/doc/html/rfc3492>, WhatWG <https://url.spec.whatwg.org/>, or any other form of relaxed parsing are out of the scope of the library Both Vinnie and I are available to answer questions about the library on the list, on the GitHub repository page <https://github.com/CPPAlliance/url>, via email <alandefreitas(a)gmail.com>, or on Slack (in #boost-url). -- Alan Freitas https://github.com/alandefreitas

5 7

Understanding the code base.
by Rahul Sharma 21 Feb '22

21 Feb '22

So far I have been reading multiple documentations and reading the projects from past year GSoC and exploring some modules given on the GitHub and I came to understand now that in order to contribute to this organization the knowledge of only C++ and data structures is not enough. I have some questions which are halting my progress so far, it would be very generous of you if someone could address these issues I am facing…… 1. I am unable to understand the code base in the repositories on GitHub. 2. In order to contribute or to understand things in a better way do I need to learn how Boost libraries work. 3. What are some packages I need to install. It would be very kind of you if you could provide some useful resources for the same and also for the things you think could be of use to understand things clearly and for making some PRs. When I read the code base of some repositories and some documentations I got excited as I think there are many things and skills I need to learn, the skills, it takes to be a decent developer. Sent from [1]Mail for Windows References 1. https://go.microsoft.com/fwlink/?LinkId=550986

2 1