- Boost - lists.boost.org

Copy_File Method Question
by Sean B 06 May '22

06 May '22

Good afternoon, Thank you for allowing me to join the group as I a newbie to the boost c++ libraries. My question I have to the development group is based on the copy_file method. Does the copy_file do a 'bit to bit' copy using (check sums and hash) or the original file? Thanks for any information on this.

2 1

C++ package managers
by Adam Getchell 06 May '22

06 May '22

For what it’s worth, having tried Biicode (Conan’s predecessor), Conan, Spack, Conda, and vcpkg, vcpkg is the only package manager for which I’ve been able to consistently (i.e. since I started using it a few years ago) build combinations of {macOS, Linux, Windows } x { gcc, clang, msvc}. As my research project includes CGAL which includes Boost, Eigen, and TBB, that ends up being 100+ libraries. Manifest mode just works, and vcpkg artifacts looks promising: https://devblogs.microsoft.com/cppblog/vcpkg-artifacts/ -- Adam Getchell acgetchell(a)ucdavis.edu https://adamgetchell.org

2 2

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