niedz., 25 sty 2026 o 21:57 Alfredo Correa <alfredo.correa@gmail.com> napisał(a):
On Sun, Jan 25, 2026 at 10:03 AM Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
niedz., 25 sty 2026 o 18:54 Andrzej Krzemienski <akrzemi1@gmail.com> napisał(a):
sob., 10 sty 2026 o 00:52 Andrzej Krzemienski <akrzemi1@gmail.com> napisał(a):
Hi Everyone, Given the recent announcement of the upcoming Boost.Multi review, I wanted to offer some initial feedback.
The docs compare this library to the existing Boost.MultiIndex in the following way:
Boost.MultiArray <https://www.boost.org/doc/libs/1_82_0/libs/multi_array/doc/user.html> is the original multidimensional array library shipped with Boost. This library can replace Boost.MultiArray in most contexts, it even fulfills the concepts of boost::multi_array_concepts::ConstMultiArrayConcept and …::MutableMultiArrayConcept. Boost.MultiArray has technical and semantic limitations that are overcome in this library, regarding layouts and references; it doesn’t support value-semantics, iterator support is limited, and it has other technical problems.
What semantic limitations and technical problems do you have in mind?
technical problems: - layouts are heap (new) allocated. (BMA tried to be too smart regarding subarrays construction) - slices work through an internal, inefficient, type erasure mechanism if I remember correctly - iterators barely work with any algorithm. definitively not with algorithms that require mutation (eg sort) - BMA doesn’t work with stateful allocators or fancy pointers (eg interprocess memory),
semantic of BMA: (some consequence of the technical points above) - references of references of values (subarrays of subarrays of arrays) have their lifetimes attached to the intermediate subarray. This doesn’t allow to go recursively through subblocking, subarrays of subarray cannot be safely returned from functions effectively. This is an unfortunate result of the design, surprises anybody that tries to make serious use of the library and it is basically unfixable. - BMA Arrays don’t have value semantics because assignment only works on arrays of equal sizes (arrays inherit the assignment precondition of subarrays, as we discussed value semantics implies no preconditions on assignment) - no move semantics, If I remember correctly - There is no flattening or true “elements” range.
Thanks. It looks like at least some of them (move semantics) could be fixed in BMA. Do I get it right that it has been attempted and concluded to be impossible?
unfortunately I cannot say that Multi fulfills the strict concepts of BMA anymore because BMA has a shape method that returns a non owning pointer to the sizes or strides. Since Multi returns this by value there is no way I can’t match the semantics of a returned pointer. The BMA concept was overespecific.
Understood. It is likely the right decision not to try too hard to fit the suboptimal concept. But given what you said, is the following excerpt from the docs (section "Appendix") 100% correct? *This library can replace Boost.MultiArray in most contexts, it even fulfills the concepts of boost::multi_array_concepts::ConstMultiArrayConcept and …::MutableMultiArrayConcept. *
A more detailed comparison would be helpful in the docs. For instance, a
reader would like to be convinced what they should choose Boost.Multi, given that Boost.MultiIndex is older and probably better battle-tested.
Sorry, I meant the comparison with Boost.MultiArray, not MultiIndex.
That was clear. If I add the points above would be helpful?
It would. The purpose of such comparisons in the docs is to help a potential user make a decision: why should I use this library rather than that one? Also, what would help is a short code snippet that demonstrates the problem with BMA, and how the corresponding code in your library doesn't have the problem.
A summary of BMA is “be prepared to be surprised by its behavior and limitations, and don’t try generic programming”
If you are interested you can try converting any Multi examples to BMA. The similarities are only skin deep.
I wish Ron Garcia can participate in this thread to hear about his take on this, but I haven’t seen him around in Boost for more than a decade.
Even if he is not around, he might be interested in offering feedback. Has he been contacted?
If I remember correctly Glenn Fernandez did some retrofitting less than 10 years ago, but i don’t remember the details, something related to allocators or move semantics.
Don’t get me wrong BMA was a tour de force at the time.
Sure. This is clear. This is how we evolve things. Regards, &rzej;