- Boost - lists.preview.boost.org

Re: [boost] Mixing C++ language versions
by Glen Fernandes 12 May '22

12 May '22

On Thu, May 12, 2022 at 6:52 AM Kenneth Porter via Boost <boost(a)lists.boost.org> wrote: > > Do/will they supply multiple binaries for each C++ version? (I'm already building for > each architecture plus release/debug. Adding the compiler version explodes > the number of binaries to build and test.) The variants you have so far are: - Architecture - Release or Debug I've known library vendors to even have the following variants: - Architecture - Release or Debug - C++ standard version - Static or dynamic linking with the C++ runtime library - Single or multi threaded versions of the C++ runtime library (at one point in time) Shipping library sources to your users (instead of binaries) might be easier. Glen

1 0

[filesystem] create_directories fails on exFat formatted disk under Windows
by Chris Trueman 12 May '22

12 May '22

Using an exFat formatted disk with Windows. Start with a path: e:\tmp Call filesystem::create_directories("e:\\tmp\\boost") This should succeed, creating the boost folder in e:\tmp. It fails with boost 1.79.0. It tries to create e:\tmp which already exists. In boost 1.78.0 this works as expected. I believe the root cause is the change to status(...). It calls detail::symlink_status(...) which calls GetFileInformationByHandleEx which (at least for the params used in filesystem) doesn't work on exFat formatted disks. Chris.

2 2

SOCKS-Asio library
by Alan de Freitas 11 May '22

11 May '22

Hi, everyone! I've been writing this library for SOCKS4/5 based on Asio. The library is very embryonic but there's enough to connect to proxy servers and relay messages. I could really use some negative feedback. If anyone would like to give it a try, here are the links: Repo: https://github.com/alandefreitas/socks_proto Docs: https://develop.socks-proto.cpp.al/ #boost-socks on Slack Thanks! -- Alan Freitas https://github.com/alandefreitas

2 1

Re: [boost] Boost Digest, Vol 6699, Issue 1
by Benedict Bede McNamara 08 May '22

08 May '22

You need modules urgently. Sent from Mail for Windows From: boost-request(a)lists.boost.org Sent: Sunday, 8 May 2022 10:00 PM To: boost(a)lists.boost.org Subject: Boost Digest, Vol 6699, Issue 1 Send Boost mailing list submissions to boost(a)lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.boost.org/mailman/listinfo.cgi/boost or, via email, send a message with subject or body 'help' to boost-request(a)lists.boost.org You can reach the person managing the list at boost-owner(a)lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost digest..." The boost archives may be found at: http://lists.boost.org/Archives/boost/ Today's Topics: 1. Re: Any objections to making C++14 the current baseline for Boost support and testing? (Seth) 2. Re: Any objections to making C++14 the current baseline for Boost support and testing? (Christopher Kormanyos) 3. Re: Any objections to making C++14 the current baseline for Boost support and testing? (Bo Persson) ---------------------------------------------------------------------- Message: 1 Date: Sat, 07 May 2022 15:30:08 +0200 From: Seth <bugs(a)sehe.nl> To: "Boost List" <boost(a)lists.boost.org> Subject: Re: [boost] Any objections to making C++14 the current baseline for Boost support and testing? Message-ID: <e76334c1-625a-4ee2-999f-75959822562b(a)www.fastmail.com> Content-Type: text/plain > Even though 14 has lotsof bug fixes, > the only real key advanced featureis relaxed constexpr constraints > anddigit separators. I'd say that polymorphic lambdas, lambda capture initializers, return type deduction, decltype(auto) are all more important and really felt. I can live without the library features (because they're easy to provide, except the UDLs) ------------------------------ Message: 2 Date: Sun, 8 May 2022 09:31:19 +0000 (UTC) From: Christopher Kormanyos <e_float(a)yahoo.com> To: Boost List <boost(a)lists.boost.org> Subject: Re: [boost] Any objections to making C++14 the current baseline for Boost support and testing? Message-ID: <1679327021.415697.1652002279472(a)mail.yahoo.com> Content-Type: text/plain; charset=UTF-8 >> Even though 14 has lotsof bug fixes, >> the only real key advanced featureis>> relaxed constexpr constraints >> and digit separators. I apologize for my perhaps unwisely chosen(or even wrong) wording. > I'd say that polymorphic lambdas, lambda> capture initializers, return type deduction,> decltype(auto) are all more important> and really felt. ... And I do respect this comment. But I'm not quite ready to give upon eleven just yet... Let's argue the controversial C++11/14baseline issue from a purely service-oriented,product-management point of view. Boost has a deep symbiosis with C++11and vice-versa. There are clients usingBoost with C++11. To drop C++11 from a product/servicepoint of view should only be allowed ifa viable option is provided --- freelyand easily obtained --- for those clientsusing Boost with C++11. So I would say, prove to the clients,prove to ourselves what this optionactually is. Which option will allowclients stuck on C++11 (maybe notby choice) to continue to use Boostwithout C++11 support? One possibility comes to mind:Freeze at 1.80 if you need C++11,but I don't like this option. Kind regards, Chris On Saturday, May 7, 2022, 03:36:26 PM GMT+2, Seth via Boost <boost(a)lists.boost.org> wrote: > Even though 14 has lotsof bug fixes, > the only real key advanced featureis relaxed constexpr constraints > anddigit separators. I'd say that polymorphic lambdas, lambda capture initializers, return type deduction, decltype(auto) are all more important and really felt. I can live without the library features (because they're easy to provide, except the UDLs) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ------------------------------ Message: 3 Date: Sun, 8 May 2022 12:37:00 +0200 From: Bo Persson <bo(a)bo-persson.se> To: boost(a)lists.boost.org Subject: Re: [boost] Any objections to making C++14 the current baseline for Boost support and testing? Message-ID: <t586gu$cfq$1(a)ciao.gmane.io> Content-Type: text/plain; charset=UTF-8; format=flowed On 2022-05-08 at 11:31, Christopher Kormanyos via Boost wrote: > >> Even though 14 has lotsof bug fixes, >> the only real key advanced featureis>> relaxed constexpr constraints >> and digit separators. > I apologize for my perhaps unwisely chosen(or even wrong) wording. > >> I'd say that polymorphic lambdas, lambda> capture initializers, return type deduction,> decltype(auto) are all more important> and really felt. > ... And I do respect this comment. > But I'm not quite ready to give upon eleven just yet... > > Let's argue the controversial C++11/14baseline issue from a purely service-oriented,product-management point of view. > Boost has a deep symbiosis with C++11and vice-versa. There are clients usingBoost with C++11. > To drop C++11 from a product/servicepoint of view should only be allowed ifa viable option is provided --- freelyand easily obtained --- for those clientsusing Boost with C++11. > So I would say, prove to the clients,prove to ourselves what this optionactually is. Which option will allowclients stuck on C++11 (maybe notby choice) to continue to use Boostwithout C++11 support? It can also be argued that we might do some clients a disservice instead of a service. If the new features are *that* useful for the library authors, would they not be equally useful for the clients' code? By supporting old compilers and standards we let them procrastinate for another couple of years. Is that good? Or should we encourage them to move on? Perhaps a gentle push is all they need? "New and improved" is often used in product-marketing. Why not here? > One possibility comes to mind:Freeze at 1.80 if you need C++11,but I don't like this option. > > Kind regards, Chris > > ------------------------------ Subject: Digest Footer _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ------------------------------ End of Boost Digest, Vol 6699, Issue 1 **************************************

2 1

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