- Boost - lists.boost.org

[boost][multi] Feedback on `restrictions`
by Andrzej Krzemienski 25 Jan '26

25 Jan '26

Hi All, "Restrictions" (lazy arrays) in Boost.Multi look like a useful and practical component. The below feedback may sound negative, but it should be treated as suggestions for improving the feature. I find the name "restriction" surprising. Is this a term of art? "Lazy array" immediately conveys the idea, so I wonder why you decided to go with "restriction". I already complained that the "Reference" section is not serving its purpose well. Regarding "restrictions", they are simply missing from that section. Having read the tutorial, and wanting to use the feature in my program, I need to know: 1. Which header to include 2. What is the type returned by the "wedge" operator 3. Is the return type something that I should be able to name, use? Or is the contract "just assign the result to your array, and don't ask for the type name"? 4. What are the preconditions of the operation? 5. Are there things that I can do wrong when using the function and resulting types? 7. Does the function that I provide need to have the same number of arguments as the number of dimensions in the `extents` that I provide? 8.Do you guarantee that the index values that will be passed to subsequent invocations of my function will come in specific order? Or do I need to make sure that my function is pure/regular? 9. Does the function that I provide need to be copyable? 10. Header `restriction.hpp` has functions `make_restriction()` defined. Are they intended for users? If so, they need to be listed in "Reference"' also. I question the choice of using an arbitrary operator for creating lazy arrays. It makes the user code difficult to read and understand. I imagine that in my company I assign a junior developer to fix something in the code, and they are exposed to these bitwise-xor operators. This is an unnecessary confusion. A named factory function like `make_lazy` would immediately sell the intent: it combines the extents with an "indexes-to-value" function to produce a lazy array. It looks like there is an implied concept in your library, "non-mutable array access"., which probably includes being the RHS of the assignment to a "mutable array access". Now I feel even stronger that it should be given a name and be defined, even if semi-formally. The tutorial for restrictions mentions the function ".home()". Is this intended to be part of the library's interface? If so, it must appear in the "Reference" section. The Reference section defines what is the intended interface of the library as opposed to declarations that happen to exist in the headers for other reasons: as temporary solutions, implementation details, experiments or artifacts. Regards, &rzej;

2 6

Fwd: [Boost.Multi] Initial feedback
by Andrzej Krzemienski 23 Jan '26

23 Jan '26

Forwarding my private reply to the entire group... ---------- Forwarded message --------- Od: Andrzej Krzemienski <akrzemi1(a)gmail.com> Date: czw., 22 sty 2026 o 09:50 Subject: Re: [Boost.Multi] Initial feedback To: Alfredo Correa <alfredo.correa(a)gmail.com> czw., 22 sty 2026 o 04:08 Alfredo Correa <alfredo.correa(a)gmail.com> napisał(a): > On Wed, Jan 21, 2026 at 1:56 PM Andrzej Krzemienski <akrzemi1(a)gmail.com> > wrote: > >> >>>> What do you mean by contract? >>> >> >> All the characteristics that are usually described when documenting the >> Standard Library functions: >> https://cppreference.com/w/cpp/utility/optional/transform.html >> >> Like: return type, constraints, const/constexpr properties, >> postconditions. >> In this case, I was interested in what properties the returned range has: >> random-access, contiguous? I naturally expect that it is a contiguous range >> for multi::array and multi::array_ref, so I wanted to confirm that. I >> suppose it is different for subarrays. I can hardly imagine they would have >> the same range category. >> > > return type: A custom `elements_type`, which is a random access range. > for `multi::array` the type is `multi::subarray<T, 1>` because it can be > contiguous. > > no contraints, .elements() always returns something valid, even if the > array is empty. > it is constexpr. > postcontions, nothing changes, .elements() is just another view. > > I say this now: "As an alternative, the elements can be iterated in a > flat manner, using the `.elements()` member. > This "elements" range also provides the `begin` and `end` iterators > (`.elements().begin()`) and indexing, in the canonical order of the > original arrays (rightmost index changes fastest). > The elements range is always random-access, but it can be contiguous > depending on the original array (`multi::array` generally give contiguous > element ranges.)" > > In the reference section, > ``` > | `elements` | a flatted random-access > view of all the elements rearranged canonically. `A.elements()[0] -> > A[0][0]`, `A.elements()[1] -> A[0][1]`, etc. The type of the result is not > a subarray but a special kind of random-access range. Takes no arguments. > ``` > > And, later for array_ref, > ``` > | `elements` | a flatten random-access and contiguous view of all > the elements in the array in canonical order. (This is overwritten from the > base class, to provide contiguous access) > ``` > Ok, so about these `elements()`: 1. Regarding the array_ref member, I request that you specify this more formally: that the returned type models the concept std::ranges::contiguous_range. This already implies that it is random-access. A range need not be copyable, if you want this to be part of the guarantee, say that the return type is a view that models std::ranges::contiguous_range. 2. Regarding the array member, the fact that it might be contiguous is also a useful guarantee. Could the docs be more specific under what circumstances I get a contiguous range? Regards, &rzej; > I also added that all member functions are constexpr unless specified > differently. (almost all member functions are constexpr, a couple of > exceptions is some destructors and some constructors, due to C++17 > limitations). > > >> >> >>> >>> The search box leads me to: "a flatted view of all the elements >>> rearranged canonically. A.elements()[0] → A[0][0], A.elements()[1] → >>> A[0][1], etc. The type of the result is not a subarray but a special kind >>> of range. Takes no argument." >>> >> >> It takes me to subarray::elements, but that doesn't imply that >> array::elements would have the same contract. >> "special kind of range" is not the level of detail that I expected. I >> think you owe the user the range category. >> > > range category: always random access, contiguous for multi::array. > > Thanks, > Alfredo >

2 1

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

23 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 20

Intro & Request for Boost Stories
by Mark Cooper 21 Jan '26

21 Jan '26

Hello everyone, I'm Mark Cooper, CMO at The C++ Alliance. I just wanted to introduce myself, and let you know that I'm always looking out for new examples of how the community is building / using Boost. So if you're working on anything that you think the C++ world would find interesting, send me an email at mark(a)cppalliance.org. Thank you, Mark

1 0

Boost Libraries are Obsolete
by Vinnie Falco 18 Jan '26

18 Jan '26

I believe some Boost libraries become obsolete by newer versions of C++. For example, boost::filesystem, Boost.CharConv, and Boost.Variant could be considered obsolete in versions C++17 and later as these facilities are in the standard. It can be tricky to figure out what is obsolete. Is boost::shared_ptr obsolete in C++11? Probably not since it has features not found in the standard. Anyway, I'm not trying to figure this out for all the libraries. For boost.org it might be nice to let users specify the "minimum version of C++" which they use. And they can opt in to filtering the Libraries based on this minimum version. Someone who is using C++23 can choose not to see libraries like Boost.Align, Boost.Assign, or Boost.Atomic. We will need to add metadata to each library's repository to know the maximum version. What do you all think about this? -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

6 8

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

[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