Live data from Hacker News

Debunking that C++ is faster and safer than Rust

viva64.com

71–80 of 84 posts

Re: Debunking that C++ is faster and safer than Rust

#71

Earlier quoted context omitted.

Okay, you're very confused. You're getting it almost backwards. Undefined behavior is behavior that the language does not define , not behavior that the implementation is prohibited from defining. That's why you can't treat it like (for example) a random-number generator. Implementations are well within their rights (i.e. 100% consistent with the language) to define previously-undefined behavior to be anything . They…

I do absolutely understand that UB does not prohibit implementations from defining something. That’s part of the core of what we’re taking about! I’m saying rustc chooses to never do so. C and C++ compilers do choose to do so. That distinction is what we’re talking about. (As well as that overflow is UB in one language and not another, of course.)

No comment on everything else I wrote beyond that 1 sentence? Your positions are quite contradictory, which is what I've been trying to explain in the entire comment.

Re: Debunking that C++ is faster and safer than Rust

#72

Earlier quoted context omitted.

> A huge fraction of the time you'll just step out of the bounds of an array, just deterministically instead of nondeterministically. Well arrays are bounds checked by default in Rust, so you can't do that one. You're more likely to hit a crash, which I think is decidedly better than the compiler deciding to optimise out or rewrite your function because it contained UB.

> Well arrays are bounds checked by default in Rust, so you can't do that one. But that's my entire point. If you're observing a benefit here, it's decidedly not due to the wrap-around, but due to other features (like bounds checking), and the argument should be that those features make Rust better than C++. It seems strange to give praise to the multiplication wrap-around instead.

I think I get what you're saying. The practical benefit of defining signed integer overflow in C, without any other changes, might not be very big for most C programs, since they're likely to get an out-of-bounds access either way. I'd add to that that undefined signed overflow makes it much harder to write good C code. Even if you carefully check all your array bounds, an unexpected integer promotion somewhere in there might lead the optimizer to delete the check you wrote.

Re: Debunking that C++ is faster and safer than Rust

#73

Earlier quoted context omitted.

I do absolutely understand that UB does not prohibit implementations from defining something. That’s part of the core of what we’re taking about! I’m saying rustc chooses to never do so. C and C++ compilers do choose to do so. That distinction is what we’re talking about. (As well as that overflow is UB in one language and not another, of course.)

No comment on everything else I wrote beyond that 1 sentence? Your positions are quite contradictory, which is what I've been trying to explain in the entire comment.

I just don't think we're going to get anywhere, but wanted to correct the assertion that I do not understand this aspect of UB.

Re: Debunking that C++ is faster and safer than Rust

#74

Earlier quoted context omitted.

No comment on everything else I wrote beyond that 1 sentence? Your positions are quite contradictory, which is what I've been trying to explain in the entire comment.

I just don't think we're going to get anywhere, but wanted to correct the assertion that I do not understand this aspect of UB.

I mean, your positions are contradictory, but sure.

Re: Debunking that C++ is faster and safer than Rust

#75

Very interesting article. Most of the time I do not like myth busting articles because they are to much focused on opinions and taking things out of context but this one is very well written and fully based on facts on both sides. Thanks for sharing.

Thank you!

Re: Debunking that C++ is faster and safer than Rust

#76

Earlier quoted context omitted.

I mean, if you're doing two's complement arithmetic as the example relies on then it's certainly useful. If you want any other behavior, then it is not. (Rust's differing behavior between different optimization levels IMO makes it basically impossible to use usefully, FWIW.)

How likely is that "if", though? How often when you see signed multiplication in code do you find people are actually paying attention to the negative results and planning around 2's complement behavior? I know there are occasions in which people do this, but it's so incredibly rare compared to when they multiply two numbers. And on the rare occasions when the bit patterns actually matter to them and they're paying a…

If it wasn't clear, I'm saying that making the behavior defined is nice, but personally I think defining it to wrap is not the best way it could have been done. IMO a consistent trap would have been nicer.

Re: Debunking that C++ is faster and safer than Rust

#77

Earlier quoted context omitted.

> Well arrays are bounds checked by default in Rust, so you can't do that one. But that's my entire point. If you're observing a benefit here, it's decidedly not due to the wrap-around, but due to other features (like bounds checking), and the argument should be that those features make Rust better than C++. It seems strange to give praise to the multiplication wrap-around instead.

I think I get what you're saying. The practical benefit of defining signed integer overflow in C, without any other changes, might not be very big for most C programs, since they're likely to get an out-of-bounds access either way. I'd add to that that undefined signed overflow makes it much harder to write good C code. Even if you carefully check all your array bounds, an unexpected integer promotion somewhere in th…

C is a strawman though when we're discussing C++. Checking array bounds in C (or I'd argue, pretty much checking anything in C) is just a losing battle. The lack of proper abstraction facilities perpetually fights against you. C++ actually lets you abstract checks away into the definitions so that you don't have to modify every usage site.

Regarding optimizers deleting your checks though: is that something you encounter in practice, or just something you see people ranting about in blog posts? Can you even trigger this behavior if you try? Have you seen it happen more than once in a blue moon? I know on my end it's either never happened to me (likely) or it's been long enough ago that I have no memory of it. Even when I actively go out of my way to make this kind of thing happen, it gives me a hard time. Even the most blatant examples you'd try don't end up getting optimized out like this. Try [1] for example. It's both out of bounds and an uninitialized read, and yet the check is still there. If anything it's incredibly disappointing how bad optimizers are at optimizing out bounds checks!

[1] https://gcc.godbolt.org/z/i-FMV-

Re: Debunking that C++ is faster and safer than Rust

#78

Earlier quoted context omitted.

Xbox 360 still ran in 32bit mode with the exception of the hypervisor. No use of 64bit pointers on a system with a max of 1GB of RAM other than just wasting cache space, and there's no real other benefit tacked on like you see in other 64-bit archs.

Thanks I didn't know this. I just looked up since when PowerPc 64-bit is a think.

Ah. In that case the PowerPC 620 was a 64 bit design from the late nineties.

Re: Debunking that C++ is faster and safer than Rust

#79
post #40
post #3

This is an endlessly perplexing headline, as its core assertion, "C++ is faster and safer than Rust", is what the body of the article spends its whole time attempting to refute. A more accurate title for the content of this article would be "Debunking the myths that Rust is not safer or as fast as C++".

Ok, we've debunked the title above.

Are comments about the title of articles offtopic? Because sometimes comments that discuss titles, without being inflammatory, are flagged, and sometimes they aren't.

Re: Debunking that C++ is faster and safer than Rust

#80

This article is a bit click-baity. It's more about busting myths by a particular C++ programmer against rust. Anyway for a truth (well maybe it is a myth?) that we can't bust yet... Rust is simply not available on all platforms that C++ is. Two platforms that I think are missing: * 16-bit MS-DOS * 32-bit PowerPC (Linux)

> * 16-bit MS-DOS That's not entirely true - you actually can create .COM executables: https://github.com/ellbrid/rust_dos

That's 32-bit DOS, not the same.
Post reply on HN