mdspan VS papers

Why not use https://github.com/kokkos/mdspan though ?

It can be the base of whatever *you* write via bindings generators like pybind11. In that sense, the answer to your question is "however you like". For actual simulation code, you'll see a lot more legacy Fortran and C. That said, with things like mdspan maybe being standardized (proposal), efforts towards a standard linear algebra library, and the existence of ubiquitous HPC frameworks already having been written in C++, I would say it's only a matter of time before C++ accounts for an even bigger share of all HPC code.

I'm aware of only two relevant projects myself, I don't know much, came to reddit kind of by chance. One of the multi-dimensional array libraries proposed for potential standardisation, and a gnu machine learning library that was discontinued which could be worked off of. There's probably a lot more out there, but don't get distracted from making something awesome :)

As u/IyeOnline already made the important points about VLAs and std::vector, I would just add that you may find std::mdspan to be a helpful data structure. You can allocate 1d memory and give it a 2d shape of k with nice 2d indexing, eg auto& elem = mymdspan(row, col);.

Kokkos mdspan

The good thing here is that it heavily relies on mdpsan that is a multidimensional view that handle shape and strides. And kokkos provide a C++14 compatible implementation with a complete CUDA support.

It is slowly making its way through the standards committee. https://github.com/cplusplus/papers/issues/43

The author has a fork of clang and gcc with some pretty impressive speedups, so I’m hopeful! https://lists.isocpp.org/sg14/2024/04/1127.php

What's fun is, because everything is decided in papers, we can find out why! https://github.com/cplusplus/papers/issues/884

Accepted paper here: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p20...

> The proposed std::print function improves usability, avoids allocating a temporary std::string object and calling operator<< which performs formatted I/O on text that is already formatted. The number of function calls is reduced to one which, together with std::vformat-like type erasure, results in much smaller binary code (see § 13 Binary code).

Additionally,

> Another problem is formatting of Unicode text:

> std::cout << "Привет, κόσμος!";

> If the source and execution encoding is UTF-8 this will produce the expected output on most GNU/Linux and macOS systems. Unfortunately on Windows it is almost guaranteed to produce mojibake despite the fact that the system is fully capable of printing Unicode

See https://github.com/cplusplus/papers/issues/557

Bringing editions to C++ failed, and I am not aware of anyone trying to tackle the issues https://github.com/cplusplus/papers/issues/631

(I could be wrong though! I follow the committee more than you may guess, but not as much as to think I know everything about what's going on.)

GitHub would not be relevant in this respect because:

* It's owned by a (single) commercial corporation, Microsoft.

* There is censorship both by content and in some respects by country of origin.

* The code is closed.

but otherwise it's an interesting idea.

The C++ standardization committee uses GitHub to track papers submitted to them, see:

https://github.com/cplusplus/papers

There was no non-approval. The facility needs more work, and the authors (and the committee) were focusing on getting print/format done first. I hope that the paper will be worked on again in the future. We will be happy to review it once there is a revision (see github for history)

For more details on what we did at the 2023-06 Varna meeting, the [GitHub issue](https://github.com/cplusplus/papers/issues/328) associated with the paper has a summary.