- Boost - lists.boost.org

CMake and Boost
by Robert Ramey 12 Jun '24

12 Jun '24

I'm trying to figure out how to switch to CMake to build and test my libraries. I have some experience with this as I've made such files on sort of an experimental/prototype basis. However it's been some time since I messed with this so a forgot a lot. Now I'm getting serious so I have some questions. I've looked over the official CMake documentation. It seems complete but some stuff is not well explained. I've spent some time studying https://github.com/boostorg/cmake at I'm beginning to see what I have to do. Never-the-less, I still have a few questions: 1) The first lines show mkdir __build cd __build cmake .. cmake --build . Does this presume that one starts from the library directory? Does this syntax work for out of source tree builds? That is, would the following work? mkdir /temp/__build cd /temp/__build cmake .. cmake --build . (very confusing usage of leading __) ahhhh - I see a problem. I'm thinking of starting from within the directory of a particular library. I'm presuming "modular boost". Is this supported? 2) BOOST_INCLUDE_LIBRARY I would like my CMakeLists.txt file to explicitly list the direct antecedent libraries (dependencies - bad word usage). So I'd expect to see something like add_directory(../filesystem) add_directory(../regex) ... So I could just cd to .../libs/serialization cmake --build and have it build the antecedent if and only if required. 3) CMAKE_INSTALL_INCLUDEDIR I would prefer not to "install" (copy) the include files but just use the ones from their original locations. 4) BUILD_TESTING I would prefer to have my library source to look like: ... libs/serialization CMakeLists.txt // includes add_directory for subdirectorys build, test, example, profile and ... // includes add_directory for antecedent libraries like add_directory(../libs/filesystem) include // directory with include files for users of serialization library build(or src) // source files for library build CMakeLists.txt // to build library test CMakeLists.txt example CMakeLists.txt profile CMakeLists.txt Maybe the add_directory would be conditioned on a CMAKE variable. So if I invoke CMake --build test_polymorphic_binary_archive It would recursively (re)build everything necessary and nothing not necessary If I didn't specify a list of targets, it would recursively (re)build everything that needs (re)building. This seems totally reasonable and natural to me - it work like make - but better. It would dovetail with efforts to "modularize" boost. Users would only have to download libraries they actually use - if that's what they want. I realized I've glossed over a couple of details, in particular recursive inclusion of header files and likely some other stuff. I've also experimented with CMake enough to have a feeling that what I want to do is not possible. And this is the short version of what I'd like to do. Any thoughts on this?

4 5

[container] Draft development plan for Boost.Container
by Ion Gaztañaga 11 Jun '24

11 Jun '24

Hi to all, Boost.Container was accepted in 2011 when container classes were spun off from Boost.Interprocess to form a new library. At that time it offered new features like emulated move semantics for "classic" STL-like containers and some new classes like flat_map and stable_vector. During these years more containers/main features were added: - The scoped allocator Model was added in Boost 1.50 (2012) - static_vector was added in Boost 1.54 (2013) - small_vector was added in Boost 1.58 (2015) - Polymorphic Memory Resources were added in Boost 1.60 (2015) - devector was added in Boost 1.75 (2020) Lately I've been collecting some ideas about how to improve the library and keep it interesting/useful both for other Boost libraries and Boost users. I've somewhat formalized a bit some of those ideas and I'd like to share them here in order to obtain feedback from the developers. Here's the document: https://docs.google.com/document/d/1VdMTheFUczC946dP3VKPseOoUq3sVKjU73oMvK8… Note that this document does not outline a schedule for all those ideas, it's an initial description of possible developments that should be evaluated/prioritized, as developing a substantial subset of the proposals would be a huge task. Thanks in advance for your attention and comments. Best, Ion

9 27

b2 headers failing on windows?
by John Maddock 10 Jun '24

10 Jun '24

In latest CI runs, see: https://github.com/boostorg/math/actions/runs/9427754774/job/25973291514?pr… Any ideas? Thanks! John.

6 8

Boost Downloads
by Sam Darwin 07 Jun '24

07 Jun '24

Summary: Boost downloads will be hosted at a new location, with the URL format https://archives.boost.io/release/1.85.0/source/boost_1_85_0.tar.gz Details: During the last couple of years the Boost downloads have been hosted on JFrog Artifactory, and before that on Bintray. JFrog has been very generous in providing the bandwidth and hosting services. Recently, bandwidth increased into the 150TB/month range. JFrog requested the download be moved behind a CDN, or migrated to another service entirely. At the C++ Alliance, we have set up load balanced AWS EC2 instances, and configured a Fastly CDN, on the domain archives.boost.io. Fastly offered a discounted bulk rate based on the large amount of traffic. The boost.org website now shows links to the new CDN. If you are using any automated scripts that point to jfrog.io, the existing JFrog links will continue to function until December 2024. - Sam Darwin

4 5

Docs in release tarballs
by Ruben Perez 07 Jun '24

07 Jun '24

Hi all, For someone that hasn't been that long involved in Boost, it feels strange to distribute the documentation in the same release tarball as the code, specially considering the usual complains about "Boost size". I'm sure there are reasons behind it, and I'd like to learn about them. This is a candid question, out of being a newbie here. Thanks, Ruben

8 14

Re: [boost] Boost Downloads
by Tim Haines 06 Jun '24

06 Jun '24

> Summary: > > Boost downloads will be hosted at a new location, with the URL format > https://archives.boost.io/release/1.85.0/source/boost_1_85_0.tar.gz > > Details: > > During the last couple of years the Boost downloads have been hosted on > JFrog Artifactory, and before that on Bintray. JFrog has been very generous > in providing the bandwidth and hosting services. > > Recently, bandwidth increased into the 150TB/month range. JFrog requested > the download be moved behind a CDN, or migrated to another service entirely. > > At the C++ Alliance, we have set up load balanced AWS EC2 instances, and > configured a Fastly CDN, on the domain archives.boost.io. Fastly offered a > discounted bulk rate based on the large amount of traffic. > > The boost.org website now shows links to the new CDN. > > If you are using any automated scripts that point to jfrog.io, the existing > JFrog links will continue to function until December 2024. > > > - Sam Darwin I maintain the Boost spack package[1]. The versions currently available there go back to 1.39.0. However, the versions available on archives.boost.io only go back to 1.63.0. Are the older versions going to be available there or will they remain on the sourceforge hosting? Thanks. - Tim [1] https://github.com/spack/spack/blob/develop/var/spack/repos/builtin/package… P.S. I am terribly sorry if this messes up the thread. I get my messages in digest form and could not for the life of me figure out how to reply to your email directly to the list.

2 1

[JSON] Detect duplicate keys
by abbott＠dima.unige.it 04 Jun '24

04 Jun '24

Hi, Feature request: I would like the JSON parse to inform me that duplicate keys were encountered. I believe they are currently silently handled (with a last-one-wins strategy). Thanks, John Abbott

4 3

Mailman3
by Sam Darwin 04 Jun '24

04 Jun '24

Hi, Since the current Boost webserver and mailing list are quite out-of-date, it makes sense to consider the upgrade path. Mailman3 is a complete rewrite of the mailing list software. It's designed with multiple components: hyperkitty archives, postorius, and mailman-core. Dev instances have been installed. If you have any curiosity about testing mailman3 using your local email client, or sending feedback about the mailman3 experience, you can subscribe at https://lists.preview.boost.org. Send/receive emails. If you notice problems using mailman3, open an Issue at the Github repository cppalliance/boost-mailman. Now is the best time to discover issues, rather than after deployment. Lists at https://lists.preview.boost.org won't be maintained permanently. Any emails or accounts there will eventually be deleted. It's only a staging type environment. Working with the web developers we are planning to modify the appearance of the front-end UI, adding css styles, links to the boost website, and so on. Keep an eye on the test lists for updates. In the future when "going live", the idea will be to schedule (extended) planned downtime, and have a new server fully replace "lists.boost.org". Which specific boost mailing lists should be kept? It would be easier to avoid migrating all lists, if some of them are not active. Best Regards, Sam Darwin C++ Alliance

1 0

Decimal Floating Point Library Beta
by Matt Borland 31 May '24

31 May '24

Hello, For the past year Chris Kormanyos and I have been working on a new library to implement IEEE 754 decimal floating point types. We are pleased to announce the library is now in beta, and can be found at: https://github.com/cppalliance/decimal, and the documentation is at: https://cppalliance.org/decimal/decimal.html First, what are Decimal Floating Point Numbers? They are floating point numbers where the significand is stored in base-10 (decimal) instead of base-2 (binary). This means that numbers can be represented exactly avoiding cases such as the famous 0.1 + 0.2 != 0.3: https://0.30000000000000004.com. The library provides types decimal32, decimal64, and decimal128 as specified in IEEE 754 and STL-like functionality. The library is header-only, has no dependencies, and only requires C++14. It provides most of the STL functionality that you are familiar with such as <cmath>, <cstdlib>, <charconv>, etc. We are proceeding as a beta right now rather than pursuing complete boost review as we are missing STL features such as C++17 special math, and believe we can continue to increase performance. We do intend to go through the review process at a later time. Please give the library a go, and let us know how we can make it better. We look forward to any and all feedback. If you use the Cpplang slack channel I am active (from the Central European Time zone) on both #boost and #boost-decimal. On a personal note as of today I have also moved from being employed half-time to full-time with the C++ Alliance. This affords me a greater opportunity to develop and maintain new and existing Boost libraries. Matt Borland —- C++ Alliance Staff Engineer

9 19

NVCC and Unit Test Framework.
by Allen Sanderson 29 May '24

29 May '24

Hello, I am trying to sort out an odd crash on exit while using NVCC (via Kokkos-CUDA) and the Boost Unit Test Framework. Here my are data points: Kokkos-CUDA with the Boost test tool infrastructure - Crash Kokkos-HIP with the Boost test tool infrastructure - works Kokkos-Serial with the Boost test tool infrastructure - works Pure CUDA with the Boost test tool infrastructure - works Serial with the Boost test tool infrastructure - works Kokkos-CUDA alone (e.g. normal application) - works For the first case I have three scenarios (only used to high the Kokkos usage - the code does not crash in Kokkos::initialize), two of which crash: if(true) Kokkos::initialize(argc,argv); crash in CUDA - SEGFAULTif(false) Kokkos::initialize(argc,argv); crash in elsewhere - Subprocess aborted#if 0 Kokkos::initialize() #endif No crash For the first scenario the call stack is the following: #0 0x00001555521b5d9a in ?? () from ./cuda/12.2.0/lib64/libcudart.so.12 #1 0x00001555521b8c14 in ?? () from ./cuda/12.2.0/lib64/libcudart.so.12 #2 0x000015555219d882 in ?? () from ./cuda/12.2.0/lib64/libcudart.so.12 #3 0x00001555521a072b in ?? () from ./cuda/12.2.0/lib64/libcudart.so.12 #4 0x000015554b3b5797 in __cxa_finalize () from /lib64/libc.so.6 #5 0x0000155551301a87 in __do_global_dtors_aux () from build_kokkos_cuda/library/Operators/libOperators-g.so.5.5.0 #6 0x00007fffffffad10 in ?? () #7 0x000015555532dcee in _dl_fini () at dl-fini.c:141 For second, the call stack is quite deep after the call to __cxa_finalize () otherwise the first four (4-7) are the same. At this point the only culprit I can perhaps point at is nvcc I know at that previous versions of Boost and nvcc did not get along. And such, wondering if the usage is a corner case because I know of another project that is successfully using all three Boost, Kokkos, and CUDA. I am using Boost 1.85, Kokkos 4.3, and CUDA 12.2. Any insight or thoughts ? Our unit test work with Kokkos-HIP so able to validate results. Allen Sanderson SCI Institute University of Utah

1 0