- Boost - lists.boost.org

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

[dynamic_bitset] Add at(size_type) & Support unsiged long long since C++11.
by Nya Nya 23 Apr '22

23 Apr '22

I would like to add two member functions, `at(size_type)` and `to_ullong()`, and since C++11, the constructor is promoted from `unsigned long` to `unsigned long long`. 1. at(size_type) I think it's necessary to have a member function that does bounds checking and throws exceptions. 2. dynamic_bitset(size_type, unsigned long long, const Allocator&) & to_ullong() The constructor of std::bitset is unsigned long long since C++11, and a new member function `to_ullong()` has also been added. I know this library needs to be compatible with C++03, but I think it can be solved with the macro `BOOST_NO_LONG_LONG`. Now I have submitted a pull request for the member function `at(size_type)`. If allowed, I will submit a pull request for unsigned long long later. Thanks!

1 0

Boost.URL Proposal
by Alan de Freitas 20 Apr '22

20 Apr '22

Hi, again! Now that the Boost 1.79 has shipped, I'm just passing by to remind you folks that Vinnie and I are looking for a review manager for the library that we hope will become Boost.URL. As usual, we 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). Thanks, -- Alan Freitas https://github.com/alandefreitas

3 5

Build Boost Back Better
by Vinnie Falco 20 Apr '22

20 Apr '22

Well, now that I have everyone's attention just before the release, I'd like to draw attention to the elephant in the room. That is, the declining level of activity on the Boost mailing lists and the declining level of participation in the Boost formal review process. Both in terms of the number of reviewers, and in terms of the difficulty in finding a review manager. Clearly, a website update is necessary and along with it some type of campaign to highlight once again the important role that Boost serves in the C++ community for both professionals and amateurs alike. But what more can we do? This came up before but it is worth mentioning again; in addition to a website update to make boost.org modern and relevant, how do we feel about a transition to forum-based discussion instead of the mailing list? I realize this will ruffle some feathers but surely the alternative, a descent into irrelevance due to steady declining activity is worse? Discuss. -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

29 68

Changes in buildable components over time
by Tim Haines 19 Apr '22

19 Apr '22

I've recently needed to understand which components need to be built, which are header-only, and what versions correspond to each component (i.e., when was it introduced, when was it removed). Combining the outputs from 'bootstrap.sh --show-libraries' since 1.39.0 and scraping the library listings on the website as of 1.78.0, I was able to identify everything I needed. Surprisingly, though, it appears that coroutine2 and metaparse started out as buildable components, but then switched to being header-only. coroutine2 - introduced in 1.59.0 - first buildable in 1.59.0 - last buildable in 1.64.0 - available as of 1.78.0 metaparse - introduced in 1.61.0 - first buildable in 1.61.0 - last buildable in 1.65.1 - available as of 1.78.0 I cross-referenced the release notes, but I didn't see any mention of these components being made header-only. Is this intended behavior? Thanks. - Tim

2 3