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. 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. 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? 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. 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. Thanks A