Conversation

Notices

1. Embed this notice
   niconiconi (niconiconi@mk.absturztau.be)'s status on Saturday, 30-Mar-2024 12:57:44 JST niconiconi

   #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

   • Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Haelwenn /элвэн/ :triskell: (lanodan@queer.hacktivis.me)'s status on Saturday, 30-Mar-2024 12:58:31 JST Haelwenn /элвэн/ :triskell:

     in reply to
     @niconiconi "Why are gcc/clang taking fucking ages to compile?"
   • Embed this notice
     niconiconi (niconiconi@mk.absturztau.be)'s status on Saturday, 30-Mar-2024 15:09:18 JST niconiconi

     in reply to

     • Howard Chu @ Symas

     @hyc@mastodon.social 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.

     Haelwenn /элвэн/ :triskell: likes this.
   • Embed this notice
     Howard Chu @ Symas (hyc@mastodon.social)'s status on Saturday, 30-Mar-2024 15:09:19 JST Howard Chu @ Symas

     in reply to

     @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.

   • Embed this notice
     Howard Chu @ Symas (hyc@mastodon.social)'s status on Saturday, 30-Mar-2024 15:09:20 JST Howard Chu @ Symas

     in reply to

     @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.

   • Embed this notice
     niconiconi (niconiconi@mk.absturztau.be)'s status on Saturday, 30-Mar-2024 15:09:20 JST niconiconi

     in reply to

     • Howard Chu @ Symas

     @hyc@mastodon.social Well, the flamewar between freestanders and Batteries Includers is a long and old one...