News for hackers. Stuff that matters.
Re:Speed of Rust vs. C by cygx on Saturday March 13, 2021 @09:16AM (#26446696)
That's what restrict is for:

    void foobar(struct foo *restrict f) { ... }
Re:Speed of Rust vs. C by masklinn on Saturday March 13, 2021 @12:19PM (#26448012)
And just like that we're back to

> There's a significant difference between what these languages can achieve in theory, and how they're used in practice.

Theoretically in C you can use restrict for this. Practically nobody does (rust users keep finding bugs and miscompilation in LLVM's noalias support), and it's a huge footgun because you're completely on your own and all bets are off if you misuse it.

Meanwhile in rust land, it's the default and the compiler checks your homework, and while you can always lie to the compiler it's much rarer that you'd even get in a position to do so.

Re:Speed of Rust vs. C by howinteresting on Saturday March 13, 2021 @12:21PM (#26448041)
But restrict is very hard to reason about correctly, and the consequences for making a mistake are potentially catastrophic.

There's a very real difference between what's possible in theory and what humans do in practice. I wish Hacker News people engaged more with the practice.

Re:Speed of Rust vs. C by TazeTSchnitzel on Saturday March 13, 2021 @09:22AM (#26446727)
Yes, C99 added that keyword, and you can use it in C code. (C++ is a more complicated matter, I believe…)

But I think it's pretty uncommon in practice. One reason is that the C compiler has no borrow checker to help you notice when you're using `restrict` unsafely.

(Also, there's the whole “strict aliasing” hell…)

Re:Speed of Rust vs. C by petschge on Saturday March 13, 2021 @02:34PM (#26449248)
It's not that uncommon in HPC codes. I.e. one of the places where speed matters.