- Boost - lists.boost.org

[Boost.Multi] Initial feedback
by Andrzej Krzemienski 09 Jan '26

09 Jan '26

Hi Everyone, Given the recent announcement of the upcoming Boost.Multi review, I wanted to offer some initial feedback. I would like to thank Alfredo for writing and sharing the library. I would also thank you for the single header version and the Compiler explorer integration. This is so welcoming not only for the users but also for the reviewers. I am not well familiar with the domain.i only had a look at the docs and played with toy examples in Compiler Explorer. I would like to request a Design Rationale section that would address some of the questions up front and bring some insight into the domain: 1. Is it a common need in the mentioned application fields to add a new dimension to the already stored N-dimensional data? If so, could we see an example of how to do it? 2. Why is c++17 chosen as the minimum? 3. The number of dimensions is static, but the sizes in each dimension are dynamic. Can you provide the rationale for this choice? The design: 1. I am still trying to digest the way by-reference and by-value is handled in the library in the presence of the "ref"/"view" types. It looks like the simple advice for the new users would be: * Always use `auto& ref = x` if you need the reference semantics, where `x` is whatever expression. * Always use `auto val = +x` if you need value semantics, where `x` is any expression. It looks like it is optimum even when `x` is of type `array`. 2. The initialization from values is too similar to the initialization from extents. I cannot easily figure out which initialization is used in `multi::array a({3, 4, 5});`. This is error-prone. I would prefer a longer: `multi::array a(multi::extents{3, 4, 5});`. On the other hand, does the initialization from small manual static sets of data happen often? I would think that for these use cases you would read the data from some external source. 3. If the docs recommend that all functions should be generic to account for subarrays and refs, then this library could offer a concept like `Indexable<Dimensionality, ElementType>` available for C++20 compilers. 4. Are sizes equal to strands? Does .elements() offer contiguous access? 5. For the initialization, did you consider factory functions or tag parameters? ( https://akrzemi1.wordpress.com/2016/06/29/competing-constructors/) The differentiation of meaning by braces/parens seems easy to misinterpret. 6. All the subarrays and dynamic_arrays have function swap, but it is not documented. Does it have a precondition that sizes should match? Documentation: 1.It is very clear already! 2. In the introduction it is worth explaining the term "stride-based layout" or link to the definition. This concept seems crucial to the library. 3. The docs say "or tensors in the 3D case". Tensors are arbitrary dimension. 4. I think that in real, practical use cases the array data is populated from files or datastres rather than from literals (compile-time values in braces). Could the tutorial demonstrate the endorsed way of doing such data population with this library? 5. I really appreciate that you prefix names with `multi::`. The examples could also mention the headers that you need to include. The initial docs examples may be the place where I will learn the headers. 6. The interface discoverability is not great: I wanted to quickly check the contract of `array::elements()`. I cannot find it. The reference section only has repeated text "same as for dynamic_array" (no link). Generally, the "redirect" philosophy in the reference documentation is mean.In order to look up the semantics of array::operator(), I am redirected: first from `array` to `dynamic_array`, then to `array_ref`, and only then to `subarray`. 7. Generally, we need to see a more detailed Reference section. For instance, what is the return type of operator[]? 8. Document if `array` and siblings can have dimensionality 0 (which would mean access to a single element). 9. It is strange to see a section titled "Static arrays" that describes type `dynamic_array`. In C++ "static" and "dynamic" tend to have opposite meanings. Regards, &rzej;

1 0

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

09 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 3

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

[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