stdBLAS VS papers

You can have a look at https://github.com/kokkos/stdBLAS (it's an implementation of the proposed linear algebra extensions for future C++).

It has the same BSD license as Kokkos: https://github.com/kokkos/stdBLAS/blob/main/LICENSE

The BLAS and LAPACK have C interfaces, and they generally don't allocate memory unless you ask them. (Some BLAS implementations allocate internal storage for rearranging matrix data.) There are a few C++ BLAS wrappers; here is one of them.

The second one is stdBLAS by kokkos. It doesn't even use cuBLAS but it's a reference implementation of P1673. This paper describe what could be a blas API in the std. I would recommend trying to do something equivalent on your side.

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.