#TIL C++26 is planning to add the whole BLAS into the standard library, and will natively support std::mdspan (the official multi-dimensional array since C++23). C++ surely is a programming language that people just throw everything imaginable into it. #hpc
@niconiconi imo a language spec should define only the language syntax. Nice-to-have libraries are no different than anybody else's code written in that language.
The only reason you ever needed to define a standard library for C (or C++) and its behavior is because companies were selling language implementations without library source code. If your syntax spec is solid and your compiler is correct, then you just need to provide library source code and everyone will get the same behavior.
@niconiconi when you have no library source code and different bugs in different flavors of compiler, you're forced to specify the expected behavior of unseen library code because nobody can rely on what's going on inside the library.
@niconiconi@hyc
I could argue that a library such as BLAS should perhaps be a system library tuned for the hardware and available to all higher level code; not have an implementation tied to a specific language.
@niconiconi but it's obvious there is a right and wrong in that argument. C used to be a language that could be implemented in itself, but isn't any more. It is now broken, because the spec makes it illegal to write functions like memcpy() in user code; they're only legal in the specially blessed standard library, which gets to ignore some of the braindead typing rules. When your language spec only works via special case exceptions to the rules, it's a broken spec.
@hyc memcpy() is no longer a library function today, it also works like a special code annotation. I believe calling a dummy memcpy() is one legal way to do type punning. If you do it yourself by casting pointers, the result is undefined. If memcpy() does it, it's implementation-defined - which usually gets optimized into a noop by the compiler anyway, if direct access to the underlying memory is acceptable for a particular machine (not always, e.g. alignment-to-machine-word rules).
The root of the problem is that C cannot decide whether it's a high-level or low-level language and sits on the borderline between both. Historically, programmers did all kinds of hacks inside C, like arbitrarily casting memory from and to char * (K&R didn't even have void), or the famous "you're not expected to understand this", which relied on compiler-specific register allocation. But when it became a general-purpose language, for portability and optimizations, only a subset of all possible C code is allowed, which is the part that only operates on "entities" rather than bytes without making assumption about the underlying machine or data representation.
But of course machine-specific assumptions must be made somewhere down the chain. How should the intention of the programmers in these kinds of code be expressed or communicated to the compiler is never systematically considered when C was originally designed.
Add comment