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

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

Future of C++ and Boost
by Vinnie Falco 13 May '22

13 May '22

It might be interesting to think about where C++ and Boost will be in the next 20 years and in the next 50 years. There has been an explosion of research and development into new programming languages (Rust being the most visible example). C++ is hardly the most popular language (Python is, if the TIOBE index is to be believed). But C++ is an essential language because it occupies the unique position of being as close as possible to assembly language while remaining high level. The zero-cost abstractions, metaprogramming, and powerful compositional tools of C++ still have no competitors and they are unlikely to have them any time soon. This doesn't necessarily mean that C++ is good for everything; there's an opportunity cost for all this. C++ code is generally more complex, harder to read, and harder to write than other code. Other languages are much better suited for certain tasks. No one should be implementing a content-driven website using Asio and Beast for example. But for the things that C++ is good at, it excels at them. A recent reddit post [1] provided a decent list:: * games * databases * high frequency trading * search (Google/Bing/DuckDuckGo) * web browsers (Chrome/Safari/Edge) * virtual reality headsets (Facebook) * distributed systems at big tech companies (Google/Microsoft/Facebook) * low level libraries (machine learning libraries like tensorflow and pytorch) * compilers, virtual machines, interpreters (JVM/gcc/LLVM) * robotics & hardware (ex: self driving cars, planes, missiles, space ships, etc) My opinion is that wg21 (the C++ standards committee) has been growing increasingly out of touch with the needs of the larger C++ community. Not necessarily out of malice, but because the bureaucratic process of the committee does not align the incentives of its members with users. I predict that we will see the C++ standard library become increasingly irrelevant by not only failing to produce stable things that people want, but also by not even keeping up feature-wise with the library ecosystem of other languages. Where is Requests [2] for C++? Python has had this for over a decade. In case you think I'm exaggerating, look at this comment from Reddit: ...a major vendor is getting ready to release a product that does not allow user applications to directly access TCP sockets so the only way to get any network access is to go through their standard library which only supports backdoored HTTPS. This vendor of course is Apple, as can be seen in P1860R0 [4]. We should not expect that wg21 will be able to deliver an important feature such as networking in a form that will be usable or recognizable to non-committee members. What does this mean for C++ and Boost? I believe there is a significant opportunity for Boost to step in and become the rational collection of actually useful libraries that the C++ standard library is not. We already have networking, some protocols, and JSON. We (the existing Boost authors and contributors) might consider looking to the list above of industries that use C++, and focus our efforts more towards providing libraries that enhance those industries. Perhaps by reaching out to leaders in those fields we might establish working relationships and build, say, the next Boost.Tensorflow or something like that. I don't know. Oh, and add "cryptocurrency" to the list above. C++ is the language of blockchain, because performance matters. What do you think? Thanks Vinnie [1] <https://www.reddit.com/r/cpp/comments/u5vjni/comment/i54qbzq> [2] <https://docs.python-requests.org/en/latest/> [3] <https://www.reddit.com/r/cpp/comments/u6z8gr/comment/i5caxr6> [4] <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1860r0.html>

22 50

Boost Community Maintenance Team Repository List
by James E. King III 28 Apr '22

28 Apr '22

Is the list of current CMT repositories accurate? I have been updating them with the latest GitHub Actions + Appveyor builds: https://svn.boost.org/trac10/wiki/CommunityMaintenance For reference, I maintain a spreadsheet on the current CI state of the CMT repositories as well as others I maintain and some I have assisted with - specifically to track their CI status: https://docs.google.com/spreadsheets/d/1aFdTMdJmmD9L5IyvJx-nj3BrMVztmlNo8Qw… Thanks, Jim

3 4

[dynamic_bitset] commit review - assist
by James E. King III 27 Apr '22

27 Apr '22

I could use some additional eyes on a few commits from a new submitter, if anyone wants to take a look. Hopefully I am going down the right path in my pedanticism. Thanks, - Jim

2 1

[release] Boost 1.79.0
by Marshall Clow 26 Apr '22

26 Apr '22

Release 1.79.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 numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.79.0> You can also download directly from: <https://boostorg.jfrog.io/artifactory/main/release/1.79.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, Michael Caisse, Glen Fernandes

9 17

Cross-compile for Apple Silicon on an x86 Mac
by Ian Emmons 26 Apr '22

26 Apr '22

I am trying to build Boost 1.79.0 shared libraries on an x86-based Mac running the latest MacOS (Monterey, 12.3.1) using the latest Xcode (13.3.1, with Apple’s clang 13.1.6). Everything works great for building shared libraries that run on an x86-based Mac. My ideal would be to build a single set of universal (a.k.a. “fat”) binaries that include both x86 and ARM code, but Boost.Build does not seem to contain an option to do that. (Such options existed in the past for Intel/PowerPC combinations and then later for 64-bit/32-bit Intel combinations.) Second best is to build two sets of binaries, one for x86 and another for ARM. I tried to do this using the option architecture=x86,arm on the b2 command line, and it does in fact build two sets of binaries with the expected file names. For instance, for filesystem it builds these two: libboost_filesystem-clang-darwin13-mt-a64-1_79.dylib libboost_filesystem-clang-darwin13-mt-x64-1_79.dylib But when I use the “file” command to inspect the types of these files, they both are reported as "Mach-O 64-bit dynamically linked shared library x86_64”. Am I doing something wrong, here? Or is there a bug in Boost.Build regarding cross-compiling? Thanks, Ian

3 2

Re: [boost] JSON parser error handling
by Vinnie Falco 26 Apr '22

26 Apr '22

On Mon, Apr 25, 2022 at 1:55 PM Kenneth Porter via Boost <boost(a)lists.boost.org> wrote: > I don't see any information on where in the source string the > parse error happened so I have to set a breakpoint in my tag_invoke > functions to figure out where the syntax errors lie. You have two potentially throwing lines: boost::json::value jv = boost::json::parse(contents); and axes = boost::json::value_to<std::vector<AxisProperties> If your exception is coming from the call to parse() and you want to know where in the string you are, then you need to change your code to create an instance of json::parser and call parser::write or parser::write_some to feed in the input. These functions return the number of characters consumed, which will be less than the amount passed in if an error occurs. In this case, the number of characters parsed successfully can be used to calculate an offset into the input buffer to determine where the syntax error happened. If your exception is coming from the call to value_to<>(), things are not so simple. The original JSON string is no longer available, and information about which json::value came from what part of the string is not stored (that would slow down the library and take up unnecessary memory). The best you can do in this case is to set up BOOST_THROW_EXCEPTION to get a breakpoint at the moment an exception is thrown, and then use a debugger to inspect the state of the program. You can also attach source file and line number information to exceptions when they are thrown (the library already does this). Boost.JSON throws all exceptions from these functions; alternatively, you could set a breakpoint in each of them to inspect the state of the program when an error is encountered: <https://github.com/boostorg/json/blob/83c364afaf31b58cfe8b97ab159c406c508f4…> Thanks

2 1

JSON parser error handling
by Kenneth Porter 25 Apr '22

25 Apr '22

I'm using Boost.JSON to load some static data into a tree of structures. The parser throws exceptions on parse errors, and I print the std::exception::what() string. (I throw them up in a messagebox in my GUI.) I see things like "not a number" when parsing a string where a number was expected. But I don't see any information on where in the source string the parse error happened so I have to set a breakpoint in my tag_invoke functions to figure out where the syntax errors lie. Is there some way to get the library to report the offset in the source string to where the parse error happens as part of the exception? Here's my top-level invocation: #include <fstream> #include <stdexcept> #define BOOST_DLL_USE_STD_FS 1 // tell program_location to return a std::filesystem::path #include <boost/dll/runtime_symbol_info.hpp> // program_location #include <boost/json/src.hpp> // header-only implementation std::ifstream is(boost::dll::program_location().replace_extension("json")); std::string contents; contents.assign(std::istreambuf_iterator<char>(is), std::istreambuf_iterator<char>()); boost::json::value jv = boost::json::parse(contents); axes = boost::json::value_to<std::vector<AxisProperties> >(jv.as_object().at("axis")); Library source and background: <https://github.com/boostorg/json>

1 0