January 2026 - Boost - lists.stage.boost.cppalliance.org

Moving boost/static_assert.hpp to Config
by Peter Dimov 07 Jan '26

07 Jan '26

As discussed last time, Andrey Semashev and I moved boost/static_assert.hpp from StaticAssert to Config in order to reduce nearly everyone's dependencies by one (there's no point pulling an entire repository for just one header file.) However, this presents some issues going forward. If I change depinst.py to properly "know" that boost/static_assert.hpp is now in Config, a lot of things break. That's because many libraries list StaticAssert as a dependency in their build.jam and CMakeLists.txt files, and since it's no longer used, depinst doesn't install it and there are errors. We could in principle go over all these (there are ~54 of them) and fix them, but in my experience, changes that break things internally for us also usually break things for others as well. So... instead, we could name the Config header boost/config/static_assert.hpp, leave boost/static_assert.hpp in StaticAssert, and have it include the Config one. This is going to be a lot less painful; people who care about the dependency would change their includes, whereas those who do not, will not. Opinions?

4 10

Boost.Multi (multidimensional arrays) library ready to request a review
by Alfredo Correa 06 Jan '26

06 Jan '26

Hello Boost community, I want to propose Boost.Multi, a modern C++ library for owning and non-owning multidimensional arrays with STL-compatible iteration, slicing, layout control, and lazy arrays/expressions. (The library requires at least C++17) I previewed the library on this mailing list before (see archives), but it is ready for review now and includes a couple of new features (such as lazy expressions, by popular demand) and much more comprehensive documentation. The library is built on current uses (at least two production codes) and on past experience (such as Boost.MultiArray, Blitz, Eigen, and std::mdspan). While mdspan provides a powerful non-owning view abstraction, Boost.Multi focuses on ownership, views, expressive multidimensional manipulation, and generic programming (STL-like iteration and algorithms, allocators, Ranges, Thrust). It is aimed at, but not limited to, numerical, scientific, and HPC-style workloads and emphasizes interoperability. The library has been in active use and refinement for some time, and it may now be ready for Boost review. I would be very grateful for: * Feedback on whether the library is suitable for Boost * Endorsements from those willing to support a formal review. I have an early endorsement from @Vinnie Falco, but additional endorsements are welcome * Guidance on the following steps to start the review process Repository: (Gitlab or Github mirrors, whatever you find more convenient) https://gitlab.com/correaa/boost-multi https://github.com/correaa/boost-multi Documentation: https://correaa.gitlab.io/boost-multi/multi.html https://correaa.github.io/boost-multi/multi.html If you encounter issues before a format review, the most efficient way would be to open an issue on GitLab or on GitHub: https://gitlab.com/correaa/boost-multi/-/issues https://github.com/correaa/boost-multi/issues Impatient? You can download the core library as a single header file https://correaa.gitlab.io/boost-multi/boost-multi.hpp (nightly updated) or try it in Godbolt: https://godbolt.org/z/KxGoP5Kq9 Want to check if it works with your favorite compiler? (probably it does, check compliance here: https://godbolt.org/z/fz6f6erq1) Want to test GPU capabilities? Please get in touch with me. What to chat? Join the Slack channel: https://cpplang.slack.com/archives/C071VGKUA5P Thank you all very much for your time and for maintaining such a valuable ecosystem. Best regards, Alfredo

3 2

[Graph] Any interest in adding Nearby Neighbors greedy TSP tour heuristic?
by matt.egyhazy＠gmail.com 02 Jan '26

02 Jan '26

Hi, I wrote the original metric_tsp_approx in BGL a long time ago and had help from Andrew Sutton to make it 'BGL ready'. Given a bit of free time over the holidays, I became interested in making some modifications to the original (various cleanup / better test harness) and then later (after a side track with Christofides TSP heuristic, which I deemed too inefficient for its upper bound benefits) I became interested in implementing a basic LK (Lin-Kernighan) solution. To do so first requires a TSP tour as a starting point. I decided to write an implementation of the greedy Nearby Neighbors heuristic to create this initial tour, which I have done. Nearby Neighbors runs faster than the metric_tsp_approx but has more erratic solution (tour) performance. It also has some different characteristics as a local greedy solution vs. metric_tsp which creates an MST across the whole graph. Is there any interest from the group in taking this heuristic as well as the LK? The LK will perform more slowly than metric_tsp_approx and much more slowly than Nearby Neighbors but also (on average) generate better tours.

2 3