lobsters score: 1 · tags: c++
While I appreciate that this blog post acknowledges that “there is truth behind the statements” that C++ carries safety risks, I think it’s still strange to even consider the arguments they (sort of) dismissed. These arguments are bordering on delusional.
I agree with the blog post that a core issue is certainty.
The post links to an article for the claim that C++ memory safety issues are overblown. That article makes the ludicrous argument that:
only three of the top 10 “most dangerous software weaknesses” are related to language safety properties
Of course, memory safe languages nearly eliminate these issues, whereas the C++ innovations that mitigate them provide far less certainty. The idea that nearly eliminating “only” 3/10 of the most dangerous software weaknesses via language choice isn’t significant is baffling.
Why should adding more and more layers of ever more “modern” C++ eventually fix this? The post itself acknowledges that it’s difficult to tell if everything is safe. It is equally difficult to tell if anything is actually using “modern” features, and the “modern” features do not do a good job at separating themselves from less “modern”, less safe components.
It really feels to me like the entire C++ community is delusional about the language. So many talks and posts I’ve seen discussing “modern” C++ glibly dismiss safety issues. They seem incapable of understanding the mental frame in which languages like Rust or Java are designed. So incapable, that even when they see some sense, as here, they are incapable of stating it as bluntly as it needs to be.
score 1 · canonical
I’m surprised that the list of issues does not include the implicit narrowing conversion from the string size to an int. (Especially since the list does complain about the implicit widening conversion in the str[] indexing expressions.)
int size = str.size();Integer conversions need a great deal of care in C and C++ so this was the first thing that caught my attention. They had a lucky escape from UB in this case since narrowing conversions are implementation-defined, and an overflow to a negative index is caught by the loop guard (because it’s designed to cope with deliberate underflow due to an empty string). But the algorithm is quietly wrong for strings longer than INT_MAX.
I’d rephrase the title to, The problem with C++ safety: “it works” is often undermined by the language.
score 1 · canonical
I’ve been coding in C++ since 1991, but I’ve finally given it up (when I have a choice) for either Swift or Rust. When I look at C++ code now (even my own) it looks like a wobbly assemblage of razor blades stuck together with scotch tape.
score 2 · canonical
As someone without C++ experience who occasionally reads blog posts from the community, I’ve always been put off of learning it by seeing these kinds of issues. I think someone else put it as ‘in C++, code that looks idiomatic is not idiomatic’.
Having to const-qualify as opposed to being immutable by default, order-dependent headers, the footgun with pre- vs post-fix operators (I had no idea about that one until reading this post).
I recently saw a comparison of C++ vs Rust which promoted C++'s “fine control of compilation” or somesuch, but from what I’ve heard from C++ programmers this is a feature they’d rather not deal with in almost all cases.
score 1 · canonical
Someone I worked with in 1991 called C++ “a double-edged razor blade.” The language has improved since then but his metaphor is still valid. Maybe it only has one edge now.
score 2 · canonical
Although the code is just a few lines long, it is already difficult to think it through in every detail. Are all special cases covered? Could this result in an infinite loop? Could this accidentally access any invalid memory location? Are there other sources of undefined behavior? I can’t be certain by just looking at it. I’d need more time, potentially much more time to really think it through.
This definition of bad code really stuck with me. I wouldn’t have really called that code bad per se, mostly because it looks almost exactly like any imperative palindrome-finding algorithm out there, but this articulates very nicely why it isn’t good.
score 1 · canonical