Hacker News new | past | comments | ask | show | jobs | submit login

For the optimisation, the compiler will even reason that e.g. iterating over the vector necessarily involves knowing the size of the vector and stopping before the end, so it doesn't need to add the bounds check at all because that's redundant. This is easier in Rust because the compiler knows nobody else can be mutating this vector while you're iterating over it - that's forbidden in the language.

So, in general, the idiomatic Rust "twiddle all these doodads" compiles to the same machine code as the idiomatic C++ for that problem, even though Rust bounds checked it and C++ didn't care. Lots of Rust checks are like this, they compile away to nothing, so long as what you did is necessarily correct. The Option<NonZeroU64> stuff a few days ago is another example. Same machine code as a C++ long integer using zero as a signal value, but with type safety.




Same applies when using C++ with bounds checking enabled, but the FUD regarding bounds checking is deep.


What happens about mutation in the C++ case though? Maybe I should just try it in Godbolt instead of bothering people on HN.


What mutation?

Naturally this only kind of works when everyone on the team goes safety first.

Doing some C style coding will just bork it, similarly to any unsafe block or FFI call in other better suited languages.

But in the subject of making juice with lemons, is way better than plain C.


Right, so long as there isn't mutation, we're golden, which is why the machine code is the same.

This is, after all, why Godbolt was first invented as I suspect you know (Matt Godbolt wondered if C++ iterators really do produce the same machine code as a hand-rolled C-style for loop, and rather than just trust an expert he built the earliest Compiler Explorer to show that yes, with real C++ code you get the same machine code, any time spent hand-rolling such loops is time wasted)


Yeah, but since there are domains where C++ is unavoidable, this is the best we can do.

By the way, this should be a nice update about the state of affairs on Android (I am yet to watch it).

"Improving Memory Safety in Android 12 Using MTE"

https://devsummit.arm.com/en/sessions/57


I don't understand what you mean by "domains where C++ is unavoidable" in this context. C++ is a choice, presumably usually a reasonable choice, but a choice, so if they wanted to people could avoid it.

Memory tagging (which is what MTE is about) reminds me of ASLR and password entropy requirements. They're slightly raising the bar which is not something I have much time for. I prefer to put the effort in to solve problems permanently so I can worry about something else instead. Whether that's a practical opportunity here is unclear though, and I think Rust is a big part of finding out.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: