- Boost - lists.boost.org

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