March 2026 - Boost - lists.boost.org

Support status for C++03 (std=c++03) in Boost [Version] on RHEL 9
by Piyush Anand 16 Apr '26

16 Apr '26

Hello Boost Community, I am currently planning a large-scale migration of a legacy codebase from SourcePro Rogue Wave to Boost. Due to strict production requirements, we must maintain the -std=c++03 flag across environments: RedHat 9 (GCC 5.x) My Question: Is there any version of Boost, which can be considered the "Long Term Support" equivalent for C++03, for which Boost also release latest patch or security vulnerabilities or actively maintain that version? From older post/blogs, it seems Boost does not manage c++03 standard and provide support of latest standard of c++ only i.e. C++14 and so on. Thanks And Regards, Piyush

5 6

[release] Master branch is now open for bug fixes
by Marshall Clow 14 Apr '26

14 Apr '26

Hi, The master branch is now open for bug fixes, test and documentation changes, but please follow the policy described in: https://github.com/boostorg/wiki/wiki/Releases%3A-Beta-Merge-Policy The next deadline: On April 1st, the master branch closes for all changes. As always, the calendar is at https://www.boost.org/calendar — The release managers

8 19

Proposing statsort for Boost.Sort
by Peter Taraba 09 Apr '26

09 Apr '26

7 17

std::core_dump() Issue 2 — Now Focused on the Boost Community
by Mark Cooper 08 Apr '26

08 Apr '26

Hi all, Issue 2 of the std::core_dump() newsletter is out: https://dl.cpp.al/newsletters/boost-newsletter-2026-03.pdf We've expanded the newsletter's focus from C++ Alliance news to the Boost community as a whole. Highlights: - Boost.URL constexpr URL parsing — malformed literals now fail at compile time, not runtime - Boost Docs Localization Pipeline — translation workflow piloted on Boost.JSON and Boost.Unordered If you'd like to contribute to next month's issue, reach out! Mark

1 1

One-time change to the release schedule (two week delay)
by Marshall Clow 26 Mar '26

26 Mar '26

Due to schedule conflicts with the release manager, we are going to postpone the 1.91.0 release for two weeks. I will be updating the calendar later today, but the important dates are: 15-Apr: Master branch closes for the 1.91.0 release 22-Apr: Scheduled release date Note that we’re currently in the post-beta period, so the following caveats still apply: Release open for bug fixes and documentation updates. Other changes by permission of a release manager. Requests to merge changes may be delayed during the week of April 6-10th. I apologize for the inconvenience. — Marshall (for the release managers)

1 0

[Regex] \r matching \n
by Olaf van der Spek 25 Mar '26

25 Mar '26

Hi, In this regex the \n matches \r. How is this defined / controlled? Is there a way to only match \n? std::string s = "[*] A\rB\n"; s = boost::regex_replace(s, boost::regex(R"(\[\*\](.+?)(\n|$))"), "<li>\\1</li>"); std::println("{}", js_encode(s)); // <li> A</li>\rB\n Regards, -- Olaf

4 8

A proposal to delay the Boost release for two weeks
by Marshall Clow 24 Mar '26

24 Mar '26

We have a small problem. Almost all of the release managers will be AFK for the week after Easter, which is the week when we’re scheduled to release 1.91.0 The current schedule is: 1-Apr: Master branch closed 2-Apr: RC1 created 8-Apr 1.91.0 released (assuming no problems) I propose to move all of those dates back two weeks. 15-Apr: Master branch closed 16-Apr: RC1 created 22-Apr 1.91.0 released (assuming no problems) Comments? — Marshall

3 2

Re: Multi Review Result
by Alfredo Correa 19 Mar '26

19 Mar '26

> Date: Mon, 16 Mar 2026 17:51:42 +0000 > From: Matt Borland <matt(a)mattborland.com> > Subject: [boost] Multi Review Result > To: "boost(a)lists.boost.org List" <boost(a)lists.boost.org> > Message-ID: <4otKiL_qCApAgTgtXPKXThbIFKkLIMk63P8vVM0NE-IthZzhBzta1GqWe > wIMTuvg8hFOGRr5ZFCP8X1xrlGJtF0KwrRIZYP-AGw2CLJlKp8=@ > mattborland.com> > Content-Type: multipart/signed; protocol="application/pgp-signature"; > micalg=pgp-sha512; > boundary="------c6d2e97bdd1cf2c5b6caf1a740c0085a140 > 8fcbcdd2b5dfcc2147cf72c1a1483"; charset=utf-8 > > Bottom Line Up Front: The library is conditionally accepted. > Thank you again to everyone who participated in the review. > Thank you all for your important reviews; they are very valuable to me. I know many people spend many hours on this. Special thanks to Matt for managing this review, with whom I will coordinate the next steps. In the coming weeks, I am going to work intensively on revamping the Reference section of the documentation, making other tweaks, and preparing a presentation. Thank you, Alfredo

2 1

Farewell to Wowbagger - End of an Era for boost.org
by René Ferdinand Rivera Morell 18 Mar '26

18 Mar '26

Dear Boost developers and community, On behalf of the Fiscal Sponsorship Committee, I'm writing today with a mix of gratitude and nostalgia to share some news: after 15 years of faithful, but rocky, service, wowbagger - the server that hosted boost.org, lists.boost.org, and subversion - is being mothballed. For many of us, it was simply there - one of those invisible pillars that kept our community connected and our work accessible to the world. It deserves a proper send-off. What happened: Rackspace recently notified customers that pricing on their legacy cloud platform is increasing significantly - effectively doubling - as they wind down the previous generation of cloud servers in favor of their next-generation platform. Migration is not automatic. After consulting with Marshall and others, we made the decision to terminate our Rackspace instances rather than absorb the increased costs or undertake a manual migration to a platform we no longer need. What this means: We (i.e. Sam Darwin) have stopped wowbagger for now. File-level backups and disk snapshots are in hand. After another week, the server will be deleted. This is purely a housekeeping matter - boost.org and lists.boost.org are already running on new, upgraded hardware and have been for some time. The old machine had been kept around as a reference for comparing web pages between the old and new sites, but the Rackspace pricing change simply accelerates a retirement that was already overdue. Nothing changes for us. The website and mailing lists continue to operate normally on their new home. Still, we wanted to take a moment to honor wowbagger's long run. 15 years is a remarkable tenure for any server, and this one carried the public face of Boost for all of that time. To everyone who set it up, maintained it, patched it at odd hours, and kept it humming along - thank you. Your work mattered more than most people ever realized. Rest well, wowbagger. You've earned it. Warm regards, Boost Fiscal Sponsorship Committee (Ion Gaztañaga, Joaquín M López Muñoz, René Ferdinand Rivera Morell)

1 0

Multi Review Result
by Matt Borland 17 Mar '26

17 Mar '26

Bottom Line Up Front: The library is conditionally accepted. Thank you again to everyone who participated in the review. For transparency, the final tally of ACCEPT/CONDITIONAL ACCEPT/REJECT, from both private and public reviews, was 1/5/2. Both rejections and nearly all conditional acceptance conditions revolved around the state of the documentation and naming. I have consolidated these conditions and related discussion on the GitHub issue tracker, rather than reiterating them here. The total number of new issues from the review period is 25. Rainer and Peter Turcan both brought up bugs or additional features for the website. I am working to address those separately with the web devs. This leads us to the singular condition of acceptance being to address the documentation related issues. Since this is a rather subjective requirement, we will be running a mini review of the library documentation in a few weeks. Several of those who conditionally accepted or rejected said they would be willing to look at the library again. This mini review period provides them a good opportunity to do so. I think this second review will give the best possible product for the initial release of Multi in Boost. Stay tuned for those dates. Thank you again for your time and participation in this review. The library is certainly better for it. Matt

3 3

[Interest] Flags: Non-intrusive, type-safe bitwise operators for enums
by tobi＠die-loews.de 17 Mar '26

17 Mar '26

Hi everyone, I would like to gauge interest in a library I've been working on called Flags, which provides type-safe, non-intrusive bitwise operators for C++ enumerations. The primary goal of the library is to make the usage of flag-like enums safer by preventing accidental mixing of different types while still allowing them to be used with standard bitwise logic. A preliminary version of the library was presented here two years ago. The reception was positive and led to an enlightening discussion with Andrey Semashev, who pointed out several flaws in the design — notably potential ODR violations and the need for argument-dependent lookup (ADL) of operators. An enhanced version was then presented at C++Now 2024, where it was also well-received. After incorporating all feedback and allowing another year for the library to mature within internal projects, I have decided to resubmit it here. Key Features: * Type-safety: Prevents accidental mixing of different enum types and disables built-in arithmetic operators for enabled enums to turn logical errors into compilation errors. * Non-intrusive: Can be opted-in for existing enums (both scoped and unscoped) without modifying their definition. Simple macro-based opt-in via BOOST_FLAGS(...) [currently intended name]. * Compile-Time Friendly: Everything is constexpr, making it usable in template arguments. * Zero Overhead: Designed as zero-cost abstraction in optimized builds. * Distinguishes between flag-sets and their negations at the type level (based on a sound mathematical model). * Requires at least C++11, uses newer features if present Resources: * Documentation: https://tobias-loew.github.io/flags/ * GitHub Repository: https://github.com/tobias-loew/flags * Boost-Mail-Archive first presentation: https://lists.boost.org/archives/list/boost@lists.boost.org/thread/EZXQFJWA… * C++Now 2024 Presentation: "Fun with Flags", https://www.youtube.com/watch?v=2dzWasWblRc * Godbolt Example: https://godbolt.org/z/PPoKaGrzc I am interested in hearing if the community sees a place for this in Boost or has any feedback on the design. Best regards, Tobias Loew

7 8

[multi] Formal Review Begins
by Matt Borland 16 Mar '26

16 Mar '26

Dear All, The review of Multi by Alfredo Correa begins today, March 5th and goes through March 15th, 2026. Multi is a modern C++ library that provides manipulation and access of data in multidimensional arrays for both CPU and GPU memory. Code: https://github.com/correaa/boost-multi Docs: https://correaa.github.io/boost-multi/multi/intro.html For reviewers, please use the master branch. Please provide feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? Do you already use it in industry? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Ensure to explicitly include with your review: ACCEPT, REJECT, or CONDITIONAL ACCEPT (with acceptance conditions). Additionally, if you would like to submit your review privately, which I will anonymize for the review report, you may send it directly to me at: matt_at_mattborland.com. Matt Borland Review Manager

8 27

Interest check: Boost.Algorithm.Statsort — O(n log log n) sorting
by Peter Taraba 13 Mar '26

13 Mar '26

4 7

Re: Boost Digest, Vol 7730, Issue 1
by Alfredo Correa 12 Mar '26

12 Mar '26

Dear Rainer, Thank you again for expanding your review and answer my points. Here is an answer to your last email. > Message: 6 > Date: Tue, 10 Mar 2026 13:37:06 +0100 > From: Rainer Deyke <rdeyke(a)gmail.com> > Subject: [boost] Re: [multi] Formal Review Begins > To: boost(a)lists.boost.org > Message-ID: <10op39i$hvt$1(a)ciao.gmane.io> > Content-Type: text/plain; charset=UTF-8; format=flowed > > On 3/9/26 20:30, Alfredo Correa via Boost wrote: > >> The proposed library uses an array-of-arrays model. > > > > > > Multi supports both models array-of-array and flattened view this is > > prominently mentioned in the documentation, in the Iteration section ( > > > https://correaa.github.io/boost-multi/multi/tutorial.html#tutorial_iteration > > ) > > My bad. I wrote my first message before fully reading the > documentation, so I (somehow) missed the elements function. > No problem. Sometimes the documentation are not engaging enough to make everything evident at first glance. I changed the "Getting Started" section to mention this right away. For example, I mention that: """" Arrays can be viewed simultaneously as a nested array or as flat set of elemets. ``` assert( A.elements().size() == 6 ); // total number of elements assert( A.elements()[6] == 6 ); assert( &A.elements()[6] == &A[1][2] ); ``` """ Then in the Advanced Usage.Iteration section I now mention your examplesm, and more, using the iterability of the extents object. https://correaa.gitlab.io/boost-multi/multi/tutorial.html#tutorial_iteration > > for(auto indices : a.extensions().elements() ) { > > apply(a, indices) = get<0>(indices) + 10*get<1>(indices); > > } > > I don't see subarray::extensions()::elements in the documentation at > all. In fact, the reference documentation for subarray::extensions() > read "returns a tuple with the extensions in each dimension", and > std::tuple does not have a elements member function. I see one > reference to multi::extensions_t and two references to > subarray::extensions_type, neither of which mentions an elements member > function. So this one isn't my fault. > > I didn't think of using std::apply here. It's a clever solution that > only works because arrays can use operator() for indexing instead of the > more obvious operator[]. That said, I would still prefer the direct > syntax "a[indeces]". > As I said in the correction to my first email, you don't have to use `apply` (there is a `apply_square` planned too). The preferred way is: ``` for(auto [i, j] : a.extensions().elements() ) { a[i][j] = i + 10*j; } ``` The geometric meaning of "rotate" is not limited to 2D. I can rotate an > object in 3D, although I have a lot more choices for the axis of rotation. > The ironic thing is that index rotating can be a geometric rotation of a tensor or an array (after all it is a relabelling of the axis). So the name is not that bad after all. .rotate_indices would be very verbose. I wish there was a pair of unary operator in C++ that can do rotation (of indices) by one and unrotation by one. Something like "a <<" or "a >>". > >> The boost::multi::array::reextent function is not clearly defined. > > > > You will obtain {{1, 2, 0}}, a default element will appear at a[0][2] > > because a[0][2] was not part of the original array. > > > > Your second option depends on some interpretation of the array as flat > > array of numbers. > > I agree that this is the correct behavior, but the documentations should > be more explicit. > ok, it is now clarified. > > > But you can do this better with restrictions, and second, variadic > > templates in a constructor can mess up think in a nasty way. > > multi::array({5, 2}, arg1, arg2, arg3); (to construct elements T{arg1, > > arg2, arg3}). > > Using a restriction eliminates the need for copy construction, but it > still requires move construction. I admit that storing non-movable > types in a multidimensional array is very niche. > Well, restrictions could in principle return r-values. Yes, it is very niche and it is very difficult to make it work and provide useful guarantees. > > Having said that I can add tagged constructor, > `multi::array(std::in_place, > > {5, 2}, arg1, arg2, arg3);` if you think it is something that you need. > > That would solve the problem. > Yes, but it will also prevent extra parameters like allocators. I can experiment a bit with this idea. Also remember that Multi supports partially formed objects. Which in principle means that types that only truly valid after assignment can be manipulated efficiently. > >> On a technical level, the web page doesn't accept arrow keys or page > >> up/down for scrolling, so I have to rely use my mouse for scrolling. > >> > > > > I am able to navigate, scroll up and down with arrow keys, page up/down, > > and space. > > I am using a state of the art (I am told), documentation format (Antora). > > All I can say is that it doesn't work for me on Firefox, my default > browser. It does work on Chromium, so this could be a browser > incompatibility issue or a conflict with one of my browser extensions. > ok, the bug has been reported. > > > >> The boost/multi/elementwise.hpp header is not documented at all in the > >> reference section. > >> > > > > It is documented here: > > > https://correaa.github.io/boost-multi/multi/tutorial.html#tutorial_elementw… > > Yes, but there's no list of functions/operators that the header > includes. Scrolling through the section, I see operators +, *, and /, > as well as function "exp". What other operators are there? I assume > that binary and unary - exist and unary + doesn't, but what about > bitwise operators? Any functions besides "exp"? > > >> The documentation for (I assume) > >> boost::multi::subarray::const_element_ref just calls it element_ref. > >> > > > > For restrictions? not necessarily, depends on the actual element > returned, > > but what is your question? > > On the page, > https://correaa.github.io/boost-multi/multi/reference.html#ref_subarray, > second table, there are two entries for "element_ref". One reads > "Reference to element type, deduced from pointer type, typically T&", > the other reads "Constant reference to element type, deduced from > pointer type, typically T const&". This is an error in the > documentation. The second entry should be labeled "const_element_ref", > not "element_ref". > yes, you are right. fixed. > > >> boost::multi::subarray::index_range and > >> boost::multi::subarray::extension_type are only described in very vague > >> terms. What are the members of these types? > > > > index_range is whatever type you put in the parenthesis notation to > > indicate a range of elements > > > > A( {2, 4} , 5 ); // is the array {A(2 , 5 ), A(3, 5} } > > > > {2, 4} is converted to index_range. > > Sure, but can I do anything else with an index range? Can I access its > members? Can I iterate over it? > yes, yes, and yes. (The members are .front(), .back(), .begin(), .end(), size()) > > > > Extension type is whatever is returned by the .extension() function (this > > is like .size() but returns a range) > > And it apparently has a member function "elements" that is completely > undocumented, given your earlier example: > > > for(auto indices : a.extensions().elements() ) { > > apply(a, indices) = get<0>(indices) + 10*get<1>(indices); > > } > yes, it will be documented > > > >> The return types of boost::multi::subarray::elements and > >> boost::multi::array_ref::elements should be documented. > >> > I will, yes > > > Well the type is a complicated type, that for the most part you don't > need > > to know about. > > > > multi::elements_range_t<int*, multi::layout_t<2, long int> > > > > > It depends on other template parameters. It suffices to know that is a > > random access range. > > So it meets the requirements of std::ranges::random_access_range. Does > it provide indexed access through operator[]? Does copying it produce a > deep or a shallow copy? Is it returned by value or reference? > yes, the copy is deep (it is also immutable). Returns a value, it is a lazy view. > I don't care about the exact type. I care about what properties the > type has. > Fair enough. > > >> boost::multi::restriction has a member function called "home" which > >> "returns an indexable cursor". I don't know what this cursor is, what > >> it does, or what members it has. > a cursor is "a pointer-semantic object to an array that forgot its extents" :) Most users should not need to use it. > > > Cursors are described in other sections. > > I will add a section on the tutorial, its uses are pretty advances. > > For arrays, It is for context in which you can't use pass-by-reference. > > I see a very brief mention of cursors in the Interoperability/CUDA > section (which I skipped over because I am not familiar with CUDA). > They are described as "a multidimensional generalization of iterators". > Based on that description, I would expect being able to point cursors at > different parts of the array (possibly by adding N-dimensional vectors > to the cursor), but there is no such example given. They are also > described as references to arrays that can be indexed and cheaply > copied, but subarray and array_ref can already be used for the same > purpose. > Nope, because subarray and array_ref are not copyable! That is a fundamental design of the library, they are not spans. > Regardless of the purpose of cursors, I expect them to be documented in > the reference section. Other sections of the documentation are fine for > what they are, but the reference section should be able to stand alone. > Yes, that is comming, I am rewriting the reference section. > > > It seems that the main technical criticism was regarding features that > you > > can opt-in, like views, but that you are not forced to use. > > I actually have fairly few technical criticisms. My main problem is > with the documentation is not only inadequate, but inadequate to the > point where I can't even review key design elements without reading the > source code because these design elements are not adequately documented. > For example, I feel that there should be bitwise operators in > multi::elementwise for completeness, but I would have to read the source > code to find out if they already exist or not. > I didn't go overboard because people already complained that there was a lot of operator overloading. So I am now overloading the most requested ones, "I want my D = A + B*C " But you are right, for consistency almost all operators should be there, starting from logical ones. > > The other main issue is naming things, which is of course one of the two > hard problems in computer science. Everything else is basically > nitpicking on my part. > I am collecting alternatives names for everything, so if you have suggestions, please let me know. exfents in place of extensions is underway. > > Direct element access is something that you consider very useful and a > > deal-breaker for any multidimensional library. > > > > I hope I convinced you that element address is a first class citizen in > the > > library and it was a priority since day one. > > Yes, the element address issue is mostly resolved. I still don't like > having to use "std::apply", but I can live with it. > No need to make compromises: ``` for(auto [i, j] : a.extensions().elements() ) { a[i][j] = i + 10*j; } ``` Is there anything specific I could tackle for a recommendation for conditional acceptance, or you think it is irrecoverable? Thank you again, Alfredo

2 1

Re: [multi] Formal Review Begins
by Gennaro Prota 11 Mar '26

11 Mar '26

Hi everyone, here's my review of Boost.Multi: = What is your evaluation of the design? *Strong, with minor concerns.* Boost.Multi's core design insight — treating a D-dimensional array as a container of (D-1)-dimensional sub-arrays, recursively — is elegant and is what enables full standard library algorithm compatibility. This is the library's primary differentiator and it works well. The type hierarchy is well-motivated. The slicing API is expressive (A(_, 1) for columns, A({0,2}, {0,2}) for sub-blocks, A.strided(2), A.transposed()). The technical rationale includes Godbolt proofs that A[i][j][k] generates identical machine code to manual pointer arithmetic at -O2. *Concerns:* - ~A operator for transposition: A bit surprising — most C++ developers expect bitwise NOT; .transposed() is also available and should be preferred. - nelems() alongside num_elements() is redundant. = What is your evaluation of the implementation? *Solid engineering with areas that need cleanup.* The layout system (detail/layout.hpp) is stride-based and recursive. Extensions use a custom detail::tuple rather than std::tuple, presumably for GPU compatibility. Memory management is correctly implemented. The force_element_trivial<T> trait for opt-in trivial treatment of std::complex types is a practical and well-motivated choice for GPU/performance. Allocator and fancy pointer support is thorough throughout, which is genuinely rare in multidimensional array libraries. *Concerns:* - Lint suppression density: The source code has about 3000 NOLINT annotations (about 200 in array_ref.hpp). Many are justified, but this volume suggests a better approach is needed. - Iterator template complexity: array_iterator carries six template parameters, making compiler error messages potentially very difficult to read. There are no static_assert or concept checks to produce friendly diagnostics. - UB in strided/transposed end() iterators: The documentation acknowledges that end() iterators for strided or transposed views may point to invalid memory (undefined behavior). For a Boost library, this must be resolved or have a fully documented, safe workaround. - dynamic_array move constructor is noexcept(false): This is deliberate but should be prominently documented. - extensions_t<D> has manually unrolled constructors for D=1 through D=6 (~100 lines of near-duplicate code in layout.hpp), which is a maintenance burden. = What is your evaluation of the documentation? *Good tutorial; the reference sections need work.* *Strengths*: - The tutorial is genuinely well-written, building from the problem (manual index computation) up to sorting rows and columns with standard library algorithms. - Godbolt links throughout allow instant verification of claims. - The technical rationale section addresses key design questions honestly (why A[i][j][k], why static dimensionality, why C++17). - Comparison tables vs. mdspan, mdarray, xtensor, Boost.MultiArray are clear and fair. - The reference page has a useful cheat-sheet table. *Weaknesses:* - No automated API reference extraction: The reference is manually written, which could make it drift from the implementation. - Thread safety is undocumented: In particular, dynamic_array is described as useful for multithreaded contexts, but no formal guarantees are stated. - No migration/interop guide from Boost.MultiArray or std::mdspan. = What is your evaluation of the potential usefulness of the library? *High.* The library fills a genuine gap in the C++ ecosystem. No other library that I know of provides this combination of: - Full standard library algorithm compatibility: You can std::sort() rows, std::transform() columns, std::copy() sub-blocks. This is impossible or extremely awkward with std::mdspan, Eigen, or Boost.MultiArray. - An owning n-dimensional container: std::mdspan is non-owning only; std::mdarray is not yet standardized. - GPU memory support (CUDA + HIP). - Fancy pointer support (e.g. boost::interprocess::offset_ptr for persistent/shared memory). Target users include scientific computing, image processing, numerical simulation, and ML/AI. The examples include a heat equation solver, LU factorization, Gauss-Jordan solve, Boost.Interprocess mapped files, MPI usage, and Boost.GIL integration — all realistic use cases. I haven't used it in production, but its feature set directly addresses pain points I've run into in scientific C++ projects. = Did you try to use the library? With which compiler(s)? Did you have any problems? *I didn't compile the library, but I reviewed the source code, test suite, examples, benchmarks and CI configuration.* = How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? *In-depth study.* I cloned the repository and read the core headers, the full documentation source, the online rendered docs, the CMakeLists.txt, the test files, the examples, and benchmarks. I examined class hierarchy, iterator design, const-correctness, allocator support, and portability workarounds. = Are you knowledgeable about the problem domain? *Moderately knowledgeable.* I'm familiar with the math concepts and have some experience with scientific computing and numerical methods. = Verdict: CONDITIONAL ACCEPT Rationale for acceptance: - Fills a genuine, well-articulated gap (see above). - The API is well-designed with clear value/reference semantic distinctions. - Broad compiler support. - Good documentation with a strong tutorial and honest technical rationale. Conditions for acceptance: - Resolve the UB in strided/transposed end() iterators. - Document thread safety guarantees. - Reduce Lint suppression density. Suggestions (not conditions): - Add a migration/interop guide for Boost.MultiArray and std::mdspan users. - Consider removing operator~() in favor of transposed() only. - Decide between nelems() and num_elements(). - Add automated API reference generation (MrDocs?). - Reduce extensions_t constructor unrolling with variadic templates where compiler support allows. -- Gennaro Prota <https://prota.dev>

3 2

[release] Boost 1.91.0 Beta 1 Release Candidate 1 is available
by Marshall Clow 11 Mar '26

11 Mar '26

Available at: <https://archives.boost.io/beta/1.91.0.beta1/source/> The SHA256 checksums are as follows: b8e78a226d2c0bd6ad4346254988dc2af15c0ae569d974e4da09e7dd0f338980 boost_1_91_0_b1_rc1.zip 866a39f4b6b1591c04bbb7d9c70ed241a794162512df0fa2ef79374b774354a3 boost_1_91_0_b1_rc1.7z d1eb15102b3379bff874894dd0c39d25a85c9c41147a2dd25215602b911125db boost_1_91_0_b1_rc1.tar.bz2 1194fb011943b4425cc6e15f3ee7272ae9c8331938c7d1bac8767850463c2e84 boost_1_91_0_b1_rc1.tar.gz As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Release managers

5 5

Proposal: "Newly Endorsed Libraries" section in release notes
by Vinnie Falco 11 Mar '26

11 Mar '26

The release notes currently cover changes to libraries shipped in each Boost release. I'd like to propose adding a small, clearly separated section called "Newly Endorsed Libraries" that lists libraries endorsed on this mailing list since the previous release. Endorsement is a community action with a public record on this list. Reporting it in the release notes documents a Boost ecosystem event, not an editorial judgment. The section would be agnostic: any library endorsed through the standard process qualifies, regardless of author or affiliation. The motivation is practical. Libraries that come to formal review with an existing user base get better reviews. A brief mention in the release notes, where attention is highest, gives endorsed libraries visibility among exactly the people most likely to test them and participate in the review. Proposed format: a short entry per library with the library name, a one-line description, a link to the endorsement thread, and a link to the library's repository. Nothing more. If there's interest I'll draft a concrete example for the 1.91 release notes. Vinnie

9 19

Boost 1.90.1 beta 1 released
by Marshall Clow 11 Mar '26

11 Mar '26

Boost release 1.91.0 beta 1 is now available at: https://archives.boost.io/beta/1.91.0.beta1/source/ The SHA256 checksums are: b8e78a226d2c0bd6ad4346254988dc2af15c0ae569d974e4da09e7dd0f338980 boost_1_91_0_b1.zip d1eb15102b3379bff874894dd0c39d25a85c9c41147a2dd25215602b911125db boost_1_91_0_b1.tar.bz2 866a39f4b6b1591c04bbb7d9c70ed241a794162512df0fa2ef79374b774354a3 boost_1_91_0_b1.7z 1194fb011943b4425cc6e15f3ee7272ae9c8331938c7d1bac8767850463c2e84 boost_1_91_0_b1.tar.gz Please try the beta and report any problems you encounter. Thanks to everyone who contributed to the release. -- The release managers

1 0

Re: [multi] Formal Review Begins
by Alfredo Correa 10 Mar '26

10 Mar '26

Hi Peter, thank you for your review Message: 3 > Date: Mon, 9 Mar 2026 13:39:02 -0700 > From: Peter Turcan <peterturcan(a)cppalliance.org> > Subject: [boost] Re: [multi] Formal Review Begins > To: "Boost developers' mailing list" <boost(a)lists.boost.org> > Message-ID: > <CABnUvfJMsz9AEa6epdBGC0= > S4fEMcum5wbathXc+-zrXG5rqZw(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > > Overall, the library should be usable with the current documentation, > though there were quite a few issues that could be considered to improve > it. Did largely like the tone of the text, the short and frequent examples, > the correct use of formatting for code syntax, and the overall structure is > about right. I appreciate the effort that has been put into this library so > far. > Thank you for the appreciation. > 1. Given that standard C++ already supports multi-dimensional arrays, I > think it could be clearer in the Introduction what this library brings to > the developer that is missing from the Standard. I would make the > differences explicit - what features the Standard does not support. Perhaps > this is just a wording change - from "Features of this library that aim to > facilitate the manipulation of multidimensional arrays include:" to > "Features > of this library, that are not present in the Standard, that aim to > facilitate the manipulation of multidimensional arrays include:". Though be > careful to add further qualification to the features if any are present, in > whole or in part, in the Standard. Is the Standard known for making > "unnecessary copies" for example, if so, articulate this issue. Same deeper > explanation for your other features. > This suggestion is accepted, I put these two sentences: "The following features of this library are not present in the Standard or generally combined in other libraries:" "For example, `std::mdspan` does not provide iterators, or generic interoperability with the rest of the STL." I also put a more specific things about mdspan in the Introduction. > 2. In the Introduction again, I would have liked some more discussion on > use cases. Multi-dimensional arrays are often used in real-time simulations > for example, to provide physical data super-quickly without the need for > equations or other computationally expensive approach. If there are other > compelling examples (AI, finance, astrophysics, etc.), great to be specific > and list them out. *This does have the effect of drawing in developers > working in those areas - particularly if you can link the unique features > of the library mentioned above to those use cases.* > Suggestion accepted: "In many simulations, space is divided into a grid, and values are stored at each grid cell. For example, arrays can represent fields of physical values, such as temperature variations within a block of material based on spatial coordinates, or velocity fields in a fluid. In a game, the state of board can be represented by placing pieces in a lattice. Arrays can also store numerical matrices, vectors, and more generally, tensors, to perform linear algebra operations. They can represent other abstract data structures, like network, graph, or store data in multiple columns. Arrays are amenable to bulk processing in computing, and also to slicing, and reductions." > 3. Nit: typo - "althoug": > > fixed > > 4. In the Intro there is this statement: Multi is a header-only library > and C++17 or later is required. > Good info, but other requirements are scattered throughout the doc. Perhaps > have a "Requirements" sub-heading and add OS/Compiler or other > requirements? Later on in the doc there is: The code requires any modern > C++ compiler (or CUDA compiler) with standard C++17 support; for > reference,... > All statements like this belong in the Requirements section, which itself > should follow the Introduction. > I put the requirements section after the introduction > 5. Nit. Odd, truncated sentence in the table section: Why is dimensionality > static and the sizes are dynamic? > *Sizes are fixed or * > Fixed to: "Why is the array's dimensionality hardcoded, while the array's sizes can be defined at runtime?" > 6. Navigation. > Scroll to the end of a page there is no navigation options - great to see " > *next*" and "*previous*" page links. Currently a bit tedious to have to > relocate my place in the TOC. > Good point. I think this is a good feature for Antora. > 7. Almost no linking to outside sources. For example, all the following > sentences could contain a link (as could many others): > Testing the library requires *Boost.Core* (headers), > The library works out-of-the-box in combination with the *Thrust *library. > The library works out of the box with Eric Niebler’s *Range-v3 *library, > *CUDA *is a dialect of C++ that allows writing pieces of code for GPU > execution, > or with the standard *MDSpan* *proposal *std::mdspan. > In the *next sectio*n instead we will see an example of arrays owned by the > library. [link to next section where this example is] > I added links on most places, at least at the start of the corresponding sections. > 8. Like the links to Compiler Explorer, but not the linking word "*online*" > or "*live*" - doesn't say what the link is to - "Compiler Explorer" or > whatever the title of the destination is would be much clearer. > I us the more explicit label "open with Compiler Explorer" > > 9. Nits. Remove unnecessary (and slightly condescending) words - *simple > *or > *a simple* adds no meaning (same for the word "very"), two examples: > Once installed, other CMake projects (targets) can depend on Multi by > adding *a* *simple *add_subdirectory ... > change this to: > Once installed, other CMake projects (targets) can depend on Multi by > adding add_subdirectory ... > Same for the following, and any other use of simply or very: > —something manual indexing *simply *cannot do cleanly at scale. > I use the more descriptive phrase: "... by adding a *single line* `add_subdirectory(my_multi_path)`" I removed all instances of *simply* and *very*. Reduced the number of *simple* occurrences. > 10. Only add brackets where really necessary, they are an obstacle to > smooth reading, such as here: > (Although most of the examples use numeric elements for conciseness, the > library is designed to hold general types (e.g. non-numeric, non-trivial > types, like std::string, other containers or, in general, user-defined > value-types.) > A (mutable) array can be assigned > (The Cereal XML and Boost XML output would have a similar structure.) > (de)serializing [spell it out "when serializing or deserializing a ..."] > - and many more examples. > All these suggestions accepted and implemented. I will not use parenthesis clauses in the future and remove more when I see them. > 11. Perhaps "Getting Started" is a friendlier title than *Primer (basic > usage)* and "Tutorials" better than *Tutorial (advanced usage)*. However, > the tutorials are not really tutorials unless they contain numerical steps > that a student can follow. As it is - *Advanced Usage Examples*, or a > similar title, is more accurate. > I copied it from other Boost documentations, but the suggestion is accepted and implemented. > > 12. Nit. Typo: Because this array is not *controled* by the library, this > type of object is called an array-reference. > Correct spelling is controlled. > > fixed 13. Nit. Typo: why the colon? > Note that this is also different from creating a named *reference:* > > (probably there was code after that) fixed > 14. Style nit. Make reference material impersonal - not "In my experience, > however, the following" more "Usage patterns can produce .....". Library > documentation is formal and not a blog post, so "opinions" are mostly > inappropriate - expressing factually with conditions is more appropriate. > fixed > > 15. Typo - sentence starting with lower case: > *which* uses the default Thrust device backend ( > fixed > > 16. Typo - upper case C needed: Why is *c++*17 chosen as the minimum? > fixed > > 17. Not crazy about punctuation in headings, for example: > *{fmt}* - would be better as "Formatting" > *Copy, and assigment (, and aliasing)* is ugly, "Copy, Assignment and > Aliasing" works better fixed > > Perhaps use Title case for headings - capitalize nouns, verbs, adjectives, > not articles, prepositions or conjunctions. Avoid punctuation if at all > possible. > fixed > > 18. Not sure about the following example code: > Compile time evaluation > constexpr auto trace() { > multi::array<int, 2> arr = {{1, 2, 3}, {4, 5, 6}, {7, 8, 9}}; > arr[2][2] = 10; > return std::accumulate(arr.diagonal().begin(), arr.diagonal().end()); > } > > static_assert( trace() == 4 + 2 + 10 ); > > If arr[2][2] is 10, shouldn't the assert be "1 + 5 + 10", or have I > misunderstood "diagonal"? > you are right the example was wrong, I corrected it. > > 19. Reference - I agree with earlier comments that the Reference should be > more complete. Each function/method should have its own page (or section) > to include a brief sentence on its purpose, then syntax, parameters, return > values, errors and exceptions, remarks for a fuller description if > necessary, and for bonus points an example, or link to an example, of its > use. > Yes, the reference section needs a lot of work. I am trying to find the right tool for this, Mr.Docs. For example. I am looking at the example from Capy. A peculiarity of this library is that many of the input and output parameters are conceptual, not concrete types. This in turn calls for a Reference for the concepts. > 20. Appendix - How to's is not appendix material - belongs after or part of > tutorials (perhaps renamed to "Advanced Use Cases" or similar). > It was a request in another review, I renamed it as FAQ. > Currently my feelings are that this library should have a CONDITIONAL > ACCEPTANCE that the features added are a significant enough improvement > over the current Standard, and that those improvements are clearly > articulated in the Introduction section of the docs. And some work on the > Headings, Reference and Navigation issues would help a lot. > > Hope this helps. > Yes, it helps a lot. Reference requires work, but I hope I solved most of the other problems. Let me know if the Intro is more convincing now. Thank you, Alfredo

1 0

Re: [multi] Formal Review Begins
by Alfredo Correa 10 Mar '26

10 Mar '26

Dear Rainer, Thank you for the two messages and for taking the time to review the library in detail. Your first message compares this library to your own library that I don't know about. While I don't want this response to be become a comparison between two libraries, I will indicate the points where you misrepresent the Multi library. I take the criticism of the first message, regarding flat iteration vs. multdimensional iterator seriously because this is exactly one of the main things the library is trying to solve. The second message is a formal review, but maybe after reading this first answer you can reconsider the library under a different light and it will be easier to respond to the second message (formal review) This email answer both messages together: On Sat, Mar 7, 2026 at 1:44 PM <boost-request(a)lists.boost.org> wrote: > > Message: 2 > Date: Sat, 7 Mar 2026 10:57:01 +0100 > From: Rainer Deyke <rdeyke(a)gmail.com> > Subject: [boost] Re: [multi] Formal Review Begins > To: boost(a)lists.boost.org > Message-ID: <10ogspe$kmt$1(a)ciao.gmane.io> > > The proposed library uses an array-of-arrays model. Multi supports both models array-of-array and flattened view this is prominently mentioned in the documentation, in the Iteration section ( https://correaa.github.io/boost-multi/multi/tutorial.html#tutorial_iteration ) > By contrast, my own > library uses an array-indexed-by-vector model. This makes iteration a > lot more convenient with my type. I do a lot of iteration in my own > code, so this is kind of a big deal. Compare: > > My multi_array type: > > multi_array<int, 2> a({5, 2}); > for (auto &element: a) { > element = 5; > } > for (auto index: a.get_bounds()) { > a[index] = get<0>(index) + get<1>(index) * 10; > } > > The proposed library: > > multi::array<int, 2> a({5, 2}); > for (auto &row: a) { > for (auto &element: row) { > element = 5; > } > } > auto [rows, columns] = a.extensions(); > for (auto row_index: rows) { > for (auto column_index: columns) { > a[row_index][column_index] = row_index + column_index * 10; > } > } > > Aside from more compact code, one advantage of this kind of flattened > access is that it makes it possible to write non-recursive generic > functions that work on arrays with different dimensionality. It should > be possible to add this kind of flat iteration to the proposed library > without breaking any existing functionality. > As I said, the library already supports the flat iteration and I agree that this is necessary, it was one of the main motivations of the library. The documentation uses the same vocabulary even. Your two cases can be written in this way with the library: multi::array<int, 2> a({5, 2}); for(auto& element : a.elements()) { element = 5; } for(auto indices : a.extensions().elements() ) { apply(a, indices) = get<0>(indices) + 10*get<1>(indices); } https://godbolt.org/z/WeWKTnrb5 This adds to Andrzej answer to this point in previous email where he correctly indicated that the first case can do with a one liner: `std::ranges::fill(a.elements(), 5);`. > The proposed library makes extensive use of array views. This is useful > both for performance and functionality, but it's also dangerous because > it can lead to unintentional data aliasing and dangling pointers. My > own approach is to just have the single owning multi_array type and no > array views at all. This means a few extra unnecessary copies of data, > but for my usage the performance penalty is completely acceptable. > Not arguing with that both approaches are acceptable. Multi supports both, if you don't want to make views you can use them as temporaries and never assign them names or return them from functions. Multi will be pretty happy to let you make copies all around, it has mechanisms for that too. > > The proposed library provides just one function for changing the extents > of an existing array: reextent. My type has member functions for > inserting and removing > rows/columns/planes/whatever-the-n-dimensional-equivalent-is, and I use > them all the time. This is no big deal, since this functionality can be > provided by external free functions. > The main reason not to provide insertion is that the library does not amortize allocations. New arrays can always be made it insert rows and columns. > ------------------------------ > > Message: 3 > Date: Sat, 7 Mar 2026 15:47:27 +0100 > From: Rainer Deyke <rdeyke(a)gmail.com> > Subject: [boost] Re: [multi] Formal Review Begins > To: boost(a)lists.boost.org > Message-ID: <10ohdpv$2ld$1(a)ciao.gmane.io> > Content-Type: text/plain; charset=UTF-8; format=flowed > > This is my formal review of Boost.Multi. > > On 3/5/26 14:26, Matt Borland via Boost wrote: > > - What is your evaluation of the design? > > While the array-of-arrays view of a multidimensional array can > (occasionally) be useful, I find the lack of direct element addressing > using a tuple/array/vector type problematic. > The library provides both array-of-array addressing and element address as illustrated in your previous message. Both of these codes are acceptable: multi::array<int, 2> a({5, 2}); for(auto& element : a.elements()) { element = 5; } for (auto &row: a) { for (auto &element: row) { element = 5; } } https://godbolt.org/z/WeWKTnrb5 > The rotated/unrotated/transposed member functions are specific cases of > the more general concept of changing the order of the dimensions. A > simple direct function should be added. > > The use of "rotated" to switch the order of dimensions is unfortunate > because it conflicts with the meaning of rotating an image, i.e. turning > this: > {{1, 2, 3}, > {4, 5, 6}, > {7, 8, 9}} > ...into this: > {{7, 4, 1}, > {8, 5, 2}, > {9, 6, 3}} > Instead, it turns it into this: > {{1, 4, 7}, > {2, 5, 8}, > {3, 6, 9}} > ...which, geometrically seen, is flipping operation over the diagonal, > not a rotation. > The name is based on the "rotation of indices", a(i, j, k) turns into a(j, k, i), etc. Take into account that the names must apply in the multidimensional context. There is a collision of interpretation in the 2D case here. > > "taked" is not a word in the English language. Based on the context, I > think the correct word is "taken". > Yes, I think both names should be provided. The idea was that all views are generated with '...ed' functions, to stress that it is not a verb, and in this case by using a colloquial conjugation of the verb `take`: https://en.wiktionary.org/wiki/taked > The use of unary operators + and ~ on arrays conflicts with the > potential elementwise use of the same operators: > > using boost::multi::elementwise; > boost::multi_array<my_class, 2> a{2, 3}; > auto b = -a; // Creates a lazily evaluated array that applies > // operator- to its elements. > auto c = +a; // Creates an eager copy of the array, without applying > // operator+ to its elements. > The encouraged use of unary operator+ helps create copies and the use of auto. multi::elemntwise::operator+ is binary. In any case, semantically both do the correct thing. I think this is the cost of blanket `using namespace ...` in the first place. Which I don't recommend. The design is a compromise. > The name "dynamic_array" implies that it is more dynamic than plain > "array", but the opposite is true. This class should be renamed, > possibly to "fixed_array" or "static_array". > It was called `static_array` until recently until I realized that the name was problematic. It is called `dynamic_array` because it uses dynamic memory and runtime sizes. This is the agreed upon meaning in the community. See also proposals for `dynarray` that is exactly the same idea, (an array in the heap without pointer invalidation). https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3810.pdf > The boost::multi::array::reextent function is not clearly defined. > Given this input: > {{1, 2}, > {3, 4}} > what happens if I call reextent({3, 1}, 0)? Do I get this: > {{1, 2, 0}} > or do I get this: > {{1, 2, 3}} > You will obtain {{1, 2, 0}}, a default element will appear at a[0][2] because a[0][2] was not part of the original array. Your second option depends on some interpretation of the array as flat array of numbers. > I don't like the name "restriction" for a lazy array. > Restriction is a well defined mathematical concept, you restrict a function to a domain. The domain is the grid of valid indices. https://en.wikipedia.org/wiki/Restriction_(mathematics) The problem with calling it "lazy" is that the meaning is too vague. Many libraries provide "lazy" sequences, they mean different things in different contexts. F > I don't like the name "extensions" for what I would call "extents". > This has been brough up before, `extensions` will be renamed `extents`. > The factory function "restricted" takes its argument in the opposite > order from how the class "restriction" takes its template arguments. Why? > restriction (the class constructor) takes the arguments in the same arguments are the rest of the library, extents, (e.g. {5, 2}) and, as second argument, the the "source" of the elements, an allocator (for multi::array) or a pointer (for multi::array_ref), and in the case of multi::restriction the second argument is the function that generates the values. restricted (the factory function) reads a restricted(f, domain), f is restricted to the domain. There are no more reasons than this. It seems that using the factory function is always more convenient. > The constructors of boost::multi::dynamic_array and boost::multi::array, > as well as the function boost::multi::array::reextent, require copy > construction. It would be more flexible to allow emplacement from any > set of variables that can be used to construct an element, similar to > std::vector::emplace_back. > I thought about this, but it is a false optimization. Basically the idea is that if you want to generate nxm copies of an elements, it is better to first make a master copy at the call site and the copy this elements. That is how std::vector constructor works. Optimizing for the 1-element arrays is not useful in the context. This is fundamentally different from ::emplace_back. Yes, you could do pretty powerful stuff this way (like having a constructor that populates the array with variable values, but using an intermediate class). But you can do this better with restrictions, and second, variadic templates in a constructor can mess up think in a nasty way. multi::array({5, 2}, arg1, arg2, arg3); (to construct elements T{arg1, arg2, arg3}). Having said that I can add tagged constructor, `multi::array(std::in_place, {5, 2}, arg1, arg2, arg3);` if you think it is something that you need. > > - What is your evaluation of the implementation? > > I only took a cursory look at it, mostly to make up for deficiencies in > the documentation. > > > - What is your evaluation of the documentation? > > It's pretty bad. > > On a technical level, the web page doesn't accept arrow keys or page > up/down for scrolling, so I have to rely use my mouse for scrolling. > I am able to navigate, scroll up and down with arrow keys, page up/down, and space. I am using a state of the art (I am told), documentation format (Antora). > Also on a technical level, the right side of some of the tables is cut > off on my web browser even though there is blank space to the right of > the table. I am forced to rely on horizontal scrolling to see the whole > table, and there isn't even a horizontal scroll bar. > Except in the reference section, I have no problems rendering the tables on web browsers, all fit nicely in my browser window (Safari on Mac, Firefox on Linux). Can you send a screenshot of what you see so Matt Borland and other from Boost can help me make them fit in your window. I see something similar to what you describe in the reference section, I will ask for help to the authors of Antora to see if they can fix it. (I think this because the table contains code) It will be fixed soon. UPDATE: Matt opened this issue: https://github.com/boostorg/boostlook/issues/174 > > The tutorial recommends using "auto &&" or "auto const &" for holding > subarrays instead of "auto". I disagree. A subarray is not a > reference, no matter how much it tries to act like one, and holding it > by reference is a good way to get a dangling reference. I am fully > aware that local variables of reference can extend the lifetime of a > temporary, but I consider it messy to rely on this unless absolutely > necessary. > The use of the library doesn't depend on you following this advice. subarrays are not language-references and you are right. You can use plain `auto` if you want to follow a more canonical convention. You don't need to rely on this, and the library itself doesn't rely on it. > The reference for functions does not include the full function > prototype, with return type and argument types. > This is being fixed. The main problem is that function returns depend on lots of template parameters so a more conceptual explanation is being preferred. Having said that this is going to improve. > The boost/multi/elementwise.hpp header is not documented at all in the > reference section. > It is documented here: https://correaa.github.io/boost-multi/multi/tutorial.html#tutorial_elementw… > > The documentation for (I assume) > boost::multi::subarray::const_element_ref just calls it element_ref. > For restrictions? not necessarily, depends on the actual element returned, but what is your question? > boost::multi::subarray::index_range and > boost::multi::subarray::extension_type are only described in very vague > terms. What are the members of these types? > index_range is whatever type you put in the parenthesis notation to indicate a range of elements A( {2, 4} , 5 ); // is the array {A(2 , 5 ), A(3, 5} } {2, 4} is converted to index_range. Extension type is whatever is returned by the .extension() function (this is like .size() but returns a range) multi::array<int, 2> a({5, 2}); a.extension(). is the range 0, 1, 2, 3, 4. It is of type subarray::extension_type. It helps writing loops for(auto idx : a.extension()) { ... a[idx] ... } > The return types of boost::multi::subarray::elements and > boost::multi::array_ref::elements should be documented. > Well the type is a complicated type, that for the most part you don't need to know about. multi::elements_range_t<int*, multi::layout_t<2, long int> > It depends on other template parameters. It suffices to know that is a random access range. > The reference for boost::multi::dynamic_array::elements says that it is > overridden from its base type. This is not true, it inherits from > boost::multi::array_ref::elements (which does override > boost::multi::subarray::elements). > You are correct. It was a copy paste problem. It is fixed now. > The references for dynamic_array and array have a bunch of references to > array_ref and dynamic_array respectively for functionality that is > ultimately inherited from subarray. It would be better to point these > references directly to where the functionality is defined. > I was discuraged from referring the documentation of the base class so i started doing copy paste. > > boost::multi::restriction has a member function called "home" which > "returns an indexable cursor". I don't know what this cursor is, what > it does, or what members it has. > Cursors are described in other sections. I will add a section on the tutorial, its uses are pretty advances. For arrays, It is for context in which you can't use pass-by-reference. > boost::multi::inplace_array is mentioned once but never documented. > I have to add a reference section for inplace_arrays. > "operator⇐" should be "operator<=". > Fixed > > - What is your evaluation of the potential usefulness > > of the library? Do you already use it in industry? > > I think a good multidimensional array type is very useful, and I use my > own multidimensional array type all the time. The question is if > boost::multi::array qualifies as a good multidimensional array type. > It seems that the main technical criticism was regarding features that you can opt-in, like views, but that you are not forced to use. Direct element access is something that you consider very useful and a deal-breaker for any multidimensional library. I hope I convinced you that element address is a first class citizen in the library and it was a priority since day one. > > > - Did you try to use the library? With which compiler(s)? Did > > you have any problems? > > No. > > > - How much effort did you put into your evaluation? > > A glance? A quick reading? In-depth study? > > I spent most of the day on it. > Thank you very much for the effort. > > - Are you knowledgeable about the problem domain? > > I've written my own multidimensional array class and I've used it > extensively. > I welcome comparisons in features and ergonomics. Your demonstrations helped me think how to express this with my library. > > Ensure to explicitly include with your review: ACCEPT, REJECT, or > CONDITIONAL ACCEPT (with acceptance conditions). > > I would love to have a good multidimensional array library in Boost. > Unfortunately, Boost.Multi is not such a library in its present state. > At the very least, I would need the following changes before I can > accept the library: > > - The documentation needs to be completed. > I am working in improving the documentation. > - I want to either be able to index the array using a > tuple/array/vector type, or a damn good rationale or why this isn't > possible. > You can do this already. > > Unfortunately the problems with the documentation are so severe that I > feel that another review is needed after the documentation is completed > before the library can be accepted. I therefore vote to REJECT this > library at the current time in its current state. > I will work intensively in the documentation points you raised, especially if that opens an opportunity for a conditional acceptance. Thank you very much, Alfredo

5 5

Fwd:
by Andrzej Krzemienski 06 Mar '26

06 Mar '26

Hi All, This is a review of the Boost.Multi library. I am not very familiar with the problem domain. My experience with multi-dimensional arrays is limited to writing `board[i * Width + j]`, which worked for my purposes. I spent maybe a week playing with the library, studying the documentation, conversing with Alfredo, and presenting the library in my workplace. I used the version available in Compiler Explorer, with no problems. Potential usefulness While I myself never needed this, I find the motivation presented in the docs convincing. Also, the existence of Boost.MultiArray is a proof of demand. It makes complex operations on sub-arrays really easy! Design The design is sound, clear, and adequate. I could very quickly grasp what components there are and what I can expect of them. From the first passages in the docs I could easily predict what components I will find in the library. The design seems natural to me. The design trade-offs are sound, well explained and convincing. I like the approach that this library offers blows and whistles from other comparable tools (NumPy), which users will use any way, but serves them in a manner that is compatible with C++'s strive for safety and clarity. I mean bitwise operations and broadcasting. I question some of the choices, like too many overloaded operators used for too many purposes. Implementation I didn't look deep into the documentation. I tested the library correctness via black box testing. My findings were reported via issues in GH. Documentation The tutorial part is very elaborate and gives a clear picture both as to the scope and to the look and feel of the library. Well done! Regarding the "Reference" part, it is in my opinion inadequate. I really expect and need a more detailed description of the details of the API. I describe this in detail in https://github.com/correaa/boost-multi/issues/130. Alfredo already addressed some of the items, but some still require addressing. Support Review managers never ask for this part, but I think it is equally important. How likely is it that the library will be well maintained after the adoption? After announcing this candidate library to the Boost Community Alfredo worked for a couple of years on improving and "socializing" it. Tickets are processed fast. Alfredo has been very responsive and entusiastic. We have the Compiler Explorer setup that enables online testing. I really appreciate this. This shows caring even for the reviewers. I recommend that the library be CONDITIONALLY ACCEPTED into Boost. The condition being improving the reference section of the documentation. I would like to thank Alfredo for writing, sharing and proposing the library for addition to Boost, and for all the work to make it easily accessible! Also, thanks to Matt for managing the review. Regards, &rzej;

2 1

A brief introduction
by Steve Gerbino 05 Mar '26

05 Mar '26

Hi all, my name is Steve Gerbino. I'm one of the principal architects of Corosio and a co-author of P4003: IoAwaitables, A Coroutine-Only Framework. My background is in systems programming, FinTech, and blockchain infrastructure. I'm excited to be part of the Boost community and look forward to contributing and meeting you all. STEVE GERBINO The content of this email is confidential and intended for the recipient specified in message only. It is strictly forbidden to share any part of this message with any third party, without a written consent of the sender. If you received this message by mistake, please reply to this message and follow with its deletion, so that we can ensure such a mistake does not occur in the future.

6 6

The Master branch is now CLOSED for the beta release
by Marshall Clow 05 Mar '26

05 Mar '26

Please do not commit or merge to the master branch The Beta RC1s will be available later today. — The release managers.

1 0

Master branch closes for the 1.91 beta TOMORROW
by Marshall Clow 03 Mar '26

03 Mar '26

Calendar is here: https://www.boost.org/calendar/ — The release managers

1 0