“C is how the computer works” is a dangerous mindset for C programmers

Post by throwaway17_17 » Tue, Mar 31, 2020, 5:53 PM UTC

gwd wrote: post #71

mpweiher wrote: post #22

Earlier quoted context omitted.

> C is not the hardware, it’s an abstract machine Not sure whether it is controversial or, not, but C is very much not an "abstract machine". There are languages which define an abstract machine, and the implementations then have to map that abstract machine onto the hardware, making sure to faithfully reproduce the semantics of that abstract machine. Squeak Smalltalk is an example of this, the VM provides the abstra…

> While there is an abstract machine of sorts defined in the standard, a lot is left out of the standard in UB... This is exactly why, on modern C compilers, you have to start thinking of C as an abstract machine -- because that's what the compiler writers think they're doing . But unlike abstract machines for older languages designed to be mathematically pure, or new abstract machines for newer languages designed to…

Post by myrrlyn » Tue, Mar 31, 2020, 5:57 PM UTC

xllao wrote: post #169

What is the output of Klabnik? Has he written anything substantial or does he just evangelize?

Post by saagarjha » Tue, Mar 31, 2020, 6:00 PM UTC

jeffdavis wrote: post #204

stiray wrote: post #171

Earlier quoted context omitted.

What is profoundly pissing me off are bunch of hipsters on the internet that are using xyz language and are constantly trying to compare everything to C. We are faster, we are better, we are more portable, we have JIT, we have reflection... and so on. Who cares what your tool for solving the problem is. Use Java, use JS, use python, go, rust... whatever suits for the task. Why do you want to compare yourself to C. Ju…

The "right tool for the job" is a myth (EDIT: exaggerating; clearly it applies in some cases). Languages don't work together very well, so you need huge, thick boundaries between them, such as serialization/deserialization. Data types don't match up, GCs require special data formats and don't line up with the GCs of other languages, other runtime weirdness, etc. At minimum, you need lots of copying/transformation of…

Post by amiga_500 » Tue, Mar 31, 2020, 6:02 PM UTC

pdimitar wrote: post #219

amiga_500 wrote: post #207

Earlier quoted context omitted.

C++ should only be used as a last resort. It's complex, development is slower, the tooling is poor, some universities have stopped teaching it. It's very hard to hire good C++ devs, and they are typically not cheap. I manage a c++ team btw. Our app has to be fast.

As your parent said, this is also an answer I can understand. Still, have you guys looked at alternatives -- and seriously evaluate them? Rust, Zig, Nim, D, others? If you tell me "we can't afford to, we have too much work" then that's also a valid answer (for a while at least).

Post by saagarjha » Tue, Mar 31, 2020, 6:04 PM UTC

kevingadd wrote: post #213

andrepd wrote: post #195

Earlier quoted context omitted.

There's no "bitcast" operator that changes the type of a value without affecting the value. The most common workaround involves going through memory and praying the compiler will optimize that away (while violating strict aliasing semantics to boot). Access through a union allow the same region of memory to be interpreted as different types. No support for multiple return values (in registers). There's structs, but t…

Using a union still has the going-through-memory problem, though. I spent a day or two trying to coax clang into doing the efficient thing with a union a couple years back when I could have gotten the job done in 30 minutes with raw assembly (alas...) RE: Return values, you'd be surprised. You can't assume you'll get properly optimized code for something like that in WebAssembly for example, despite the fact that you…