Live data from Hacker News

Undefined Behavior in C and C++ (2024)

russellw.github.io

51–60 of 234 posts

Re: Undefined Behavior in C and C++ (2024)

#51

I don’t buy the “it’s because of optimization argument”. And I especially don’t buy that UB is there for register allocation. First of all, that argument only explains UB of OOB memory accesses at best. Second, you could define the meaning of OOB by just saying “pointers are integers” and then further state that nonescaping locals don’t get addresses. Many ways you could specify that, if you cared badly enough. My fa…

> First of all, that argument only explains UB of OOB memory accesses at best.

It explains many loop-unroll and integer overflow as well.

Re: Undefined Behavior in C and C++ (2024)

#52
post #10

Earlier quoted context omitted.

> Rusts tooling is hands down better than C/++ which aids to a more streamlined and efficient development experience Would you expand on this? What was your C tooling/workflow that was inferior to your new Rust experience?

Not the GP, but the biggest one is dependency management. Cargo is just extremely good. As for the language tooling itself, static and runtime analyzers in C and C++ (and these are table stakes at this point) do not come close to the level of accuracy of the Rust compiler. If you care about writing unsafe code, Miri is orders of magnitude better at detecting UB than any runtime analyzer I've seen for C and C++.

Pacman is extremely good, too, for C. :)

Re: Undefined Behavior in C and C++ (2024)

#54
post #23

>Uninitialized data They at least fixed this in c++26. No longer UB, but "erroneous behavior". Still some random garbage value (so an uninitialized pointer will likely lead to disastrous results still), but the compiler isn't allowed to fuck up your code, it has to generate code as if it had some value.

It won't be a "random garbage value" but is instead a value the compiler chose. In effect if you don't opt out your value will always be initialized but not to a useful value you chose. You can think of this as similar to the (current, defanged and deprecated as well as unsafe) Rust std::mem::uninitialized() There were earlier attempts to make this value zero, or rather, as many 0x00 bytes as needed, because on most…

What are these worse bugs?

Re: Undefined Behavior in C and C++ (2024)

#55

We switched to Rust. Generally, are there specific domains or applications where C/C++ remain preferable? Many exist—but are there tasks Rust fundamentally cannot handle or is a weak choice?

Prototyping in any domain. It's nice to do some quick&dirty way to rapidly evaluate ideas and solutions.

I don't think C nor C++ were ever great languages for prototyping? (And definitely not better than Rust.)

Re: Undefined Behavior in C and C++ (2024)

#56

Earlier quoted context omitted.

We've only had 6-7 years of hame dev in rust. Bevy is coming along nicely and will hopefully remove these pain points

"Mit dem Angriff Steiner's wird das alles in Ordnung kommen" ;) As shitty as C++ is from today's PoV, the entire gaming industry switched over within around 3 years towards the end of the 90s. 6..7 years is a long time, and a single engine (especially when it's more or less just a runtime without editor and robust asset pipeline) won't change the bigger picture that Rust is a pretty poor choice for gamedev.

> As shitty as C++ is from today's PoV, the entire gaming industry switched over within around 3 years towards the end of the 90s.

Did they? What's your evidence? Are you including consoles?

Btw, the alternatives in the 1990s were worse than they are now, so the bar to clear for eg C or C++ were lower.

Re: Undefined Behavior in C and C++ (2024)

#57

We switched to Rust. Generally, are there specific domains or applications where C/C++ remain preferable? Many exist—but are there tasks Rust fundamentally cannot handle or is a weak choice?

Rust can do inline ASM, so finding a task Rust "fundamentally cannot handle" is almost impossible.

That's almost as vacuous as saying that Rust can implement universal Turing machines are that Rust can do FFI?

Re: Undefined Behavior in C and C++ (2024)

#58

We switched to Rust. Generally, are there specific domains or applications where C/C++ remain preferable? Many exist—but are there tasks Rust fundamentally cannot handle or is a weak choice?

> Generally, are there specific domains or applications where C/C++ remain preferable?

Well, anything were your people have more experience in the other language or the libraries are a lot better.

Re: Undefined Behavior in C and C++ (2024)

#59

We switched to Rust. Generally, are there specific domains or applications where C/C++ remain preferable? Many exist—but are there tasks Rust fundamentally cannot handle or is a weak choice?

Rust encourages a rather different "high-level" programming style that doesn't suit the domains where C excels. Pattern matching, traits, annotations, generics and functional idioms make the language verbose and semantically-complex. When you follow their best practices, the code ends up more complex than it really needs to be. C is a different kind of animal that encourages terseness and economy of expression. When…

Pattern matching should make the language less verbose, not more. (Similar for many of the other things you mentioned.)

> When you know what you are doing with C pointers, the compiler just doesn't get in the way.

Alas, it doesn't get in the way of you shooting your own foot off, too.

Rust allows unsafe and other shenanigans, if you want that.

Re: Undefined Behavior in C and C++ (2024)

#60

Earlier quoted context omitted.

I also hear that Async Rust is very bad. I have no idea; if anyone knows, how does async in Rust compare to async in C++?

I am yet to use async in c++, but I did work on a multi threaded c++ project for a few years Rust is nicer for async and MT than c++ in every way. I am pretty sure. But it's still mid. If you use Rust async aggressively you will struggle with the borrow checker and the architecture results of channel hell. If you follow the "one control thread that does everything and never blocks" you can get far, but the language d…

Go (at least before generics) was really annoying to use.

Doing anything concurrent in Go is also really annoying (be that async or with threads), because everything is mutable. Not just by default but always. So anything shared is very dangerous.

Post reply on HN