Hacker News Reader

Comment by mm321 | Hacker News Reader

> I would lose a lot of experience, libraries, a mature stable platform and job opportunities in exchange for more memory safety - something that's not a particularly pressing issue for me.

May i ask why memory issues are not a pressing issue for you? having to hunt down memory corruptions / access to dangling pointer / memory leaks is a pretty frequent occupation for me (as a C/C++ developer). There are tools like valgrind that help, but well, it is a pain to deal with these issues.

View on HN

I tend to think carefully about lifetimes, resource ownership and writing secure code. I am careful with threading, use language idioms to enforce safety and also use tools (such as valgrind, but also static analysis) to check the code.

This is not as reliable as Rust's compile-time safety checks, but in practice it works well enough for me. I don't think this is typical for all C++ projects or programmers e.g. I am not particularly impressed by the (little) Firefox code I've seen.

I hope C++ continues to evolve safety features and get closer to Rust's guarantees. I don't think automotive or aviation will switch too soon.

Out of curiosity, do you have (open-source) examples of C++ projects that do it right?

In my numerous-though-irregular years as a C++ programmers, I haven't seen any project producing code that's convincingly safe. I won't list all the pitfalls of C++ here, but, well, who doesn't have war stories of bugs-because-of-aliasing, bugs-because-of-const-doesn't-actually-mean-constant, bugs-because-pointer-is-still-being-used-after-its-mutex-has-been-released, bugs-because-collection-has-somehow-been-mutated-during-traversal, etc? I have reached the point where I feel I can't trust any non-trivial C++ code, so I gladly switched to Rust for all my new non-webdev projects.

But back to the question, I would be really happy to see convincingly safe C++ subsets in action. I certainly hope that this would improve my life as a C++ developer, at least for future projects. As a side question, I wonder how many C++ developers actually produce such code.

Don't have a link to such a project, I didn't really look. I am seriously considering starting one though, perhaps it's necessary.

I am genuinely interested.

Also, I just realized that doing this right might require dropping lots of legacy C++ code, more or less as would starting in Rust.

>I tend to think carefully..

What about a team? If you are leading a team of programmers, would you rather use Rust (where finding if the code is doing anything unsafe using a simple grep) or C++ where finding dangerous code is a lot harder?

I think the point of using langauges like Rust and Haskell only comes into play when the development is done by a team. It is one thing to hope that every one in your team is as disciplined as yourself (including yourself on a bad day), and knowing for certain that the language won't allow bad stuff to happen...

Depends on the team. If they're not experienced writing safe C++, I'd go with a safer language (e.g. Java) or teach them if that's not possible. But this also depends a lot on the project, usually it's the case that C++ is the only option available.

We can't start using any languages we want, we have to consider industry standards, resource availability and other constraints.

In legacy codebases, this is common, and I agree this is very painful. But in modern C++, it's pretty easy to write code that doesn't leak or dangle references. Don't use new, don't use delete; no memory leaks (barring cycles w/ shared_ptr). Avoid raw pointers in favor of references, and there are only a couple of rare cases where you can have something dangle. In addition, the new sanitizers (asan, msan), do what valgrind does, but are about 10 times faster, that is they only slow your code down 2-3x. So you should be running it on your unit tests on a nightly basis, further catching any bad memory issues. On a green field project, you can write code like this and have processes like this from day one, and memory safety is not going to be something you spend much time on.

I've worked on C++ codebases where I just never spent any time on this stuff, at all.

Probably because people with experience know how to handle these things up front so that they don't occur. I've been writing C and C++ for a decade now and for the last 6 years or so i have had very few issues which stem from any of the things you mention.

> Probably because people with experience know how to handle these things up front so that they don't occur. bla bla bla.

especially if you are dealing with a large code base with shifting requirements, where the code has been written over a long time by a lot of people; in a real world system you just can't make these assumptions regarding 'skill' at all. Even skilled people will have to deal with issues like invalidated iterators / containers that have been modified in non obvious ways / lots of other goodies as well.

there are a lot of projects/products like this, my guess is that this is the case with the majority of projects.

another example that i had the other day: lets say you have a cache of some sorts, now you keep adding entries to the cache without deleting them, in the end it blows up because it is out of memory. Now technically it is not a leak, but the result is that of a leak.

Now good luck solving that with smart pointers and reference counting, etc.

I don't think that bulb ever dismissed entirely the idea of learning Rust for fun or for acquiring knowledge, did he?

And it sounds like he works in the auto industry. This is pretty depressing that the paycheck weighs more heavily than the safety factor. Toyota killed people with their bad code.

From the little that I know, safety-relevant code might be modeled in a high-level language that generates C. I don't work directly on safety-relevant features, but I'm sure there are other processes and practices in place.

Some bad news for you though: all automotive companies typically use the same tools and processes. Aviation is also like that. And they use a ton of C and C++.

We had our chance and lost it, the DoD was doing great things with Ada. But 1) the compilers sucked 2) they were hard to get ahold of and 3) there wasn't nearly as much training material on how to use Ada well. Then the DoD acquiesced on Ada and permitted embedded dev in C/C++.

I am totally fine with a high level tool emitting C. C is a fine portable target. But the high level system should pass some provable rigor.

Reply on news.ycombinator.com