On 3/5/26 14:26, Matt Borland via Boost wrote:
Multi is a modern C++ library that provides manipulation and access of data in multidimensional arrays for both CPU and GPU memory. I have my own multidimensional array type that I use extensively, so I thought it would be interesting to compare my own efforts to the proposed library.
The proposed library uses an array-of-arrays model. By contrast, my own library uses an array-indexed-by-vector model. This makes iteration a lot more convenient with my type. I do a lot of iteration in my own code, so this is kind of a big deal. Compare: My multi_array type: multi_array<int, 2> a({5, 2}); for (auto &element: a) { element = 5; } for (auto index: a.get_bounds()) { a[index] = get<0>(index) + get<1>(index) * 10; } The proposed library: multi::array<int, 2> a({5, 2}); for (auto &row: a) { for (auto &element: row) { element = 5; } } auto [rows, columns] = a.extensions(); for (auto row_index: rows) { for (auto column_index: columns) { a[row_index][column_index] = row_index + column_index * 10; } } Aside from more compact code, one advantage of this kind of flattened access is that it makes it possible to write non-recursive generic functions that work on arrays with different dimensionality. It should be possible to add this kind of flat iteration to the proposed library without breaking any existing functionality. The proposed library makes extensive use of array views. This is useful both for performance and functionality, but it's also dangerous because it can lead to unintentional data aliasing and dangling pointers. My own approach is to just have the single owning multi_array type and no array views at all. This means a few extra unnecessary copies of data, but for my usage the performance penalty is completely acceptable. The proposed library provides just one function for changing the extents of an existing array: reextent. My type has member functions for inserting and removing rows/columns/planes/whatever-the-n-dimensional-equivalent-is, and I use them all the time. This is no big deal, since this functionality can be provided by external free functions. -- Rainer Deyke - rainerd@eldwood.com