Re: [boost] Boost Digest, Vol 7351, Issue 3

Hi Andrzej, Thanks for the continued conversation.

From: Andrzej Krzemienski Subject: [boost] [multi] A successor to Boost.MultiArray? Did I get it right that Multi can be considered a superior alternative to Boost.MultiArray?

yes If so, it triggers a couple of points:

* Can Boost.MultiArray be upgraded instead?

MultiArray is a superset of BMA. I have a test in the CI to show that this library fulfills all the concepts BMA defines. There are still semantic differences in BMA, such as the quality of implementation issues or plain semantic bugs. Before we go down this road, I did try many times to overhaul BMA. The architecture of BMA is beyond repair. Some obstacles seem to be even purposeful features of the library, such as disallowing the assignment of arrays of different sizes. Layout information is heap allocated. Iterators are broken and too basic. Subblock views have a complicated, inefficient implementation. The lack of responsiveness of the original authors was also an issue. Don't get me wrong, BMA was a tour-de-force at the time. It even spearheaded C++ concept checking in C++98, which I have delayed integrating into the library until C++20 Concepts. * The same questions, "is it useful at all", apply also to Boost.MultiArray.

BMA is useful in principle and was a great leap forward then. In practice, it is unfortunately almost unusable. You can tour Stackoverflow questions on #boost-multi-array and see all its pain points.

* Whatever the motivation for using Boost.MultiArray is, it should also be a good motivation for Multi.

yes

I read in the Boost.MultiArraydocs that it is a better replacement for vector>.

Yes, but this is a simplistic description. It is mainly used to explain the multi-index element access A[i][j], etc., but the analogy ends there. Of course it is a completely different data structure, vector> is more general (at a price), the "rows" can be staggered. In any case, it is, at worst a replacement for vector>> *recursively*.

So, maybe a good use case is for simple use cases, where you want to store and perform a simple access to relatively small-sized data sets, where performance is important, but not super-critical, and changing from nested vectors to Multi is already good and sufficient an optimization.

I don't know how you conclude this is for small-sized data? Do you mean that vector> would be ok for large-size data in contrast? I don't think so.

As a side note, when comparing Multi with std::mdspan. The latter requires C++23, while the former, only C++17. So, when someone has C++17, mdspan is not an option.

yes

BTW, why do you require C++17?

- The main reason was for ease of development: - implementing allocator propagation without if-constexpr is a nightmare. - c++17 provides polymorphic allocators, and I wanted to be compatible with them (at the time, I didn't know about __has_include, it was much simpler to just use C++17) - If I remember correctly, I could use some constexpr algorithms and make the arrays fully constexpr. These are not hard reasons to require C++17. I can port it to C++14 as soon as any user asks for it, but it hasn't happened yet. In fact, Vinnie Falco promised a gazillion dollars from Microsoft to port it back to C++14. ;P ( https://cpplang.slack.com/archives/C27KZLB0X/p1682786897070269) Thank you, Alfredo