- Boost - lists.boost.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?

6 19

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

Modular B2 build status ==> missing commits from master.
by René Ferdinand Rivera Morell 26 Dec '25

26 Dec '25

I finally have some slivers of time to check in on the status of the modular build changes. As of a few minutes ago there are 34 libraries that have not merged the changes to master: ==> algorithm behind 25 commits. ==> align behind 2 commits. ==> callable_traits behind 1 commits. ==> circular_buffer behind 11 commits. ==> compute behind 12 commits. ==> convert behind 9 commits. ==> date_time behind 11 commits. ==> exception behind 14 commits. ==> foreach behind 10 commits. ==> functional behind 1 commits. ==> fusion behind 3 commits. ==> graph behind 67 commits. ==> graph_parallel behind 19 commits. ==> hof behind 2 commits. ==> icl behind 23 commits. ==> io behind 1 commits. ==> local_function behind 1 commits. ==> multi_array behind 1 commits. ==> ublas behind 37 commits. ==> parameter_python behind 7 commits. ==> phoenix behind 2 commits. ==> polygon behind 11 commits. ==> property_map_parallel behind 7 commits. ==> proto behind 9 commits. ==> range behind 13 commits. ==> safe_numerics behind 45 commits. ==> scope_exit behind 12 commits. ==> serialization behind 26 commits. ==> statechart behind 1 commits. ==> tti behind 10 commits. ==> units behind 1 commits. ==> vmd behind 11 commits. ==> xpressive behind 13 commits. Would be fantastic if the libraries update their master branches for the next release. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net

1 0

[filesystem] Boost.Filesystem now treats Cygwin as a POSIX platform (was: New errors on Cygwin)
by Andrey Semashev 25 Dec '25

25 Dec '25

Hi, Following the discussion in the "New errors on Cygwin" thread, I have now switched Boost.Filesystem to treat Cygwin as a POSIX platform. The change is now in develop and is planned to be released in Boost 1.91. As noted in that thread, this is a breaking change for Cygwin users, unless they were already using a patched Boost.Filesystem to a similar effect. Among the things that are visible to users are: * The path::value_type type has changed from wchar_t to char. As on other POSIX platforms, wide character paths will be converted to the narrow character encoding using the locale set by path::imbue. Note that since Cygwin is running on top of Windows, it will also perform character code conversion internally. It is important that locale in the Cygwin environment is configured correctly. * Path syntax now follows POSIX conventions, Windows-specific paths (e.g. UNC paths, drive names and path prefixes) are not supported. * Certain Windows-specific parts of the API will become inaccessible. Since reparse points are a Windows-only feature, file_type::reparse_file will not be reported for files. Reparse point handling is dependent on Cygwin runtime behavior. * Cygwin has its own implementation of symlinks that is incompatible with native Windows symlinks. Boost.Filesystem will now create and operate on Cygwin symlinks. * Error codes reported by Boost.Filesystem will now use POSIX errno values. There may be other differences that I forgot to mention. There is no fallback option, other than patching Boost.Filesystem or staying on an older version, and this is intentional. Making this choice user-configurable opens up too many possibilities for inconsistencies and ODR issues, especially given that Boost.Filesystem is a compiled library. It would also complicate maintenance.

1 0

B2 and Visual Studio 2026
by René Ferdinand Rivera Morell 23 Dec '25

23 Dec '25

FYI, about 14 hours ago both the develop and master branches have B2 v5.4.2. It contains the changes to support recognizing the new VS 2026 release. See <https://github.com/bfgroup/b2/releases> for the substantive changes. -- -- René Ferdinand Rivera Morell -- Don't Assume Anything -- No Supongas Nada -- Robot Dreams - http://robot-dreams.net

2 2

[filesystem] New errors on Cygwin
by Gennaro Prota 23 Dec '25

23 Dec '25

Hi, I'm getting some errors from Filesystem in the Cygwin tests of DynamicBitset. I see that Filesystem is tested on Cygwin, so this is odd. Could a maintainer please have a look? Thanks. <https://github.com/boostorg/dynamic_bitset/actions/runs/20430426737/job/586…>. -- Gennaro Prota <https://prota.dev>

4 10

Cygwin patches
by David McFarland 22 Dec '25

22 Dec '25

Hi, I've created a set of patches that together allow boost to build on cygwin. - https://github.com/boostorg/asio/pull/463 - https://github.com/boostorg/context/pull/322 - https://github.com/boostorg/process/pull/533 - https://github.com/boostorg/stacktrace/pull/219 - https://github.com/boostorg/system/pull/137 I also made a tracking issue with links to all of them: - https://github.com/boostorg/boost/issues/1112

4 5

Compile failing in v1.90.0 with dynamic_bitset
by Benjamin Redelings 22 Dec '25

22 Dec '25

Hi, Software tests found a compile failing with boost v1.90 (it was just pulled in to homebrew). I filed an issue here: https://github.com/boostorg/dynamic_bitset/issues/100 Please let me know if I should be notifying someone else instead. -BenRI

3 2

[multi_index] upgrade to C++11 and potential backwards compatibility issues
by Joaquin M López Muñoz 21 Dec '25

21 Dec '25

Hi, Boost.MultiIndex has been upgraded to require C++11 a minimum, and in the process the library has been refactored to no longer use Boost.MPL and Boost.Preprocessor. The changes, benefits and potential backwards compatibility issues are explained in this external article: https://bannalia.blogspot.com/2025/12/boostmultiindex-refactored.html If you're a Boost.MultiIndex user please test this upgraded version in advance of the target Boost 1.91 release (develop branch of boostorg/multi_index) so that we have time to fix any problem that may arise. Thank you! Best, Joaquín M López Muñoz

2 2