Re: Boost Digest, Vol 7351, Issue 3

From: Alfredo Correa (alfredo.correa_at_[hidden])
Date: 2024-09-26 02:25:44

Hi Andrzej,

Thanks for the continued conversation.

> From: Andrzej Krzemienski <akrzemi1_at_[hidden]>
> 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<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<vector<...>>
is more general (at a price), the "rows" can be staggered.
In any case, it is, at worst a replacement for vector<vector<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<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