Hacker News Reader

Comment by nindalf | Hacker News Reader

I don't know about this. There are a lot of people being paid by their companies to work on the C++ committee and on various compiler teams. The author of the post we're discussing is a member of the committee and this article is an attempt to improve the security situation in C++.

So funding isn't the issue. The issue is that the committee has a firm commitment to never introducing breaking changes. This commitment is so firm that it trumps literally any other interest, like making the language memory safe. That's why the author only suggests non-breaking changes in this article.

Lots of people are going to have opinions on whether this approach is the right one for C++'s long term success, but I think we'll only know in 5-10 years.

View on HN

This :

> So funding isn't the issue.

does not follow from :

> There are a lot of people being paid by their companies to work on the C++ committee and on various compiler teams. The author of the post we're discussing is a member of the committee and this article is an attempt to improve the security situation in C++.

The people working on the C++ committee are mostly working on their own time. Specific project directly funded by companies are actually quite rare. And those mostly focus on companies very immediate needs.

If someone wanted to commit let's say 25$ million over 5 years, i am sure that both C++ standards and the major implementations would make large jump in term of safety.

> The issue is that the committee has a firm commitment to never introducing breaking changes. This commitment is so firm that it trumps literally any other interest, like making the language memory safe.

Yes C++ and its committee have very strong commitment to backward compatibility. However, that's not the reason for not wanting to make C++ memory safe : from what i understand, the committee decided that the tradeoff are not worth the gain, and as Hurb explain in this article, between tooling and reasonable default, it possible to achieve pretty good level of safety in practice.

> That's why the author only suggests non-breaking changes in this article.

Just to repeat my point here: no, Hurb is suggesting non-breaking changes because of the aforementioned commitment to back-compat. Even if breaking changes were to be introduces, they would most likely NOT be to make C++ a memory safe language whole sale

> as Hurb explain in this article, between tooling and reasonable default, it possible to achieve pretty good level of safety in practice.

This is the main contention. For those who believe in the technical leadership of the committee, this feels like a reasonable way forward.

I'm sure in theory these issues can be tackled, it's just that in practice the C++ community has always chosen performance over any other concern (https://research.swtch.com/ub). In that context, where you can change the APIs but you can't change how a whole community behaves, these articles by Sutter and Stroustrup feel like a Hail Mary play to address the valid concerns raised by multiple organisations around memory safety. I think we'll find out in 5 years if their optimism was well founded.

> it's just that in practice the C++ community has always chosen performance over any other concern (https://research.swtch.com/ub).

I don't know how much credence to give to this idea. It seems to me this specific this critic always comes from (designer of) languages with very different goal in mind.

If you ask a die hard C fan, they will point to things like exceptions handling, constructor and even type conversion as example where C++ is not making design decision purely on performance. It seems that from it's inceptions, modelisation power and type safety where paramount to C++ and it's design, right along performance.

In particular here, it hard for me not to read simply in the article you linked that the authors doesn't like the compromise that the C++ committee has chosen... Notthing really objective.

> you can't change how a whole community behaves, these articles by Sutter and Stroustrup feel like a Hail Mary play to address the valid concerns raised by multiple organisations around memory safety.

Maybe i have a different read of the situation. But we are talking about the same community which produced C++11, introducing both a memory model, thread semantic and lambda functions. And since then have produce pretty significant advance in the language every 3 years. The C++ community is more deliberate in its approach to solving issues, taking longer to make sure that the proposed solution actually address the correct problem.

> I think we'll find out in 5 years if their optimism was well founded.

True.

> That's why the author only suggests non-breaking changes in this article.

One of the proposals in the article is to change the meaning of things like "if (a != b > c)" and "if (0 <= index < max)". That changes program behavior and therefore is a breaking change (for instance, the code might accidentally be depending on the "wrong" results of these odd comparisons, and "fixing" them makes it go through an untested path which does the wrong thing).

It's ok if the current behaviour is changed into a compiler error

I agree; while changing it into a compiler error could be considered "breaking" (it no longer compiles), it's not a silent break and forces the developer to fix the code. (I would only worry about developers doing the "obvious" fix to shut the compiler up without looking at the surrounding code to see if it was masking some other bug.)

That feels imprecise to the point of rendering the entire conversation useless. If every major C++ compiler shipped a copy of `rustc` renamed to `g++` or `clang++` or whatever, that would also make every breaking change a compiler error, but I don't think that's what anybody is talking about here.

On the contrary, it's the absurd claim that making "if (a != b > c)" a compiler error is somehow remotely comparable to changing C++ syntax so that it's the same language as Rust is what renders the entire conversation useless and is not what anybody is talking about here.

that's how you get companies to stop upgrading and eventually end up sitting on a 20 y/o version of C++.

2nd and 3rd order thinking is a thing.

If a company won't update because it really needs to depend on whether one bool compares greater to another then by all means they can stick to using 20 year old version of C++.

Other companies with modern engineering disciplines that don't write hacky code like that can benefit from a sane and sensible compiler instead of being dragged down.

If you can't understand how the expense of doing that may be onerous on a business then you shouldn't be let anywhere near decision making.

Too late for that, I am in a decision making position at a quant firm with very strict engineering standards and I absolutely stand by my decision that businesses that write code that compares booleans together like that should not be in a position to hold back other businesses that don't.

They can continue using 20 year old compilers and quit making the language worse for the rest of us who have put in the effort and cost of writing modern software.

It's always easy to make a decision when you're not the one paying the cost for it, or don't imagine you will be.

In fact, one of the red flags for decision makers is the inability to understand the above tenet.

I agree, asking everyone else to pay the cost of writing error prone code because they refuse to adapt but yet feel entitled to use new compilers is a big red flag and poor technical decision making that offloads the cost on the rest of the community.

I'm glad we managed to get that out of the way.

Companies that wish to stick with their existing and deprecated coding standards can stick to their existing and deprecated compilers, allowing those of is who wish to have safe and modern tools the freedom to make progress without their baggage holding us back.

oh snap guys, do you see what he did there in his parley? The way he took my point and pretended I was saying something else and that I really agreed with him. That technique so got me that he won!

This is most definitely the paragon that should be helping us decide which large swathe of people to fuck over.

> On the contrary, it's the absurd claim that making "if (a != b > c)" a compiler error is somehow remotely comparable to changing C++ syntax so that it's the same language as Rust is what renders the entire conversation useless and is not what anybody is talking about here.

My point is that "it's okay to turn something into a compiler error" is vague and I don't know where the line is actually drawn. I don't think the boundary between acceptable and unacceptable breakage is obvious, which is why I explicitly gave an example that I knew for sure was outside it. I don't think the idea that reasonable people might disagree about what level of breakage is acceptable particularly radical, so I think it's worth not immediately assuming I'm participating in bad faith.

This is the sort of ideological thinking that holds back progress and it's something people have complained about in particular with the C++ standardization process.

You always have these purists who think that because a solution doesn't solve the problem for every single use case, that we can't put forth solutions that solve the problem for 90% of use cases. The entire article that Herb Sutter is writing is really a push to fix the 90% of safety problems in C++ without coming up with an ideologically pure solution that tries to solve all of C++'s safety problems.

If someone puts forth a proposal that a fairly awkward and easily misunderstood and error prone expression like "bool > bool" should produce a compiler error, and your response is that if we do that, we may as well just change all of C++'s syntax so that one could rename rustc to g++ and it just works, then you are participating in bad faith as opposed to presenting a sensible argument that reasonable people can actually discuss and make some kind of meaningful progress.

> If someone puts forth a proposal that a fairly awkward and easily misunderstood and error prone expression like "bool > bool" should produce a compiler error, and your response is that if we do that, we may as well just change all of C++'s syntax so that one could rename rustc to g++ and it just work

My first comment gave and example followed by saying "I don't think that's what anyone here is talking about", and my most recent response reiterated that I considered my example as explicitly being outside the boundary of what anyone would consider acceptable. It feels like you're going through great lengths to try to present it as something I actually recommended when I've been quite clear that I don't think it's anywhere close to reasonable. I've been quite clear that I'm not proposing anything; on the contrary, I'm _asking_ about how to decide whether something is a breaking change that's worth it or not because I'm not at all an expert in C++ and I don't pretend to be.

The only "ideological thinking that holds back progress" due from "purists" going on here is your insistence that I should be disqualified from asking questions because I happened to try to use a hypothetical example that you didn't like.

Why would you go from the proposal in the article that involved making a confusing expression like "bool > bool" a compiler error, to the absurd example of suggesting that C++'s syntax be changed to be identical to Rust?

How could talking that way possibly be conducive to having a serious discussion about the article, which is trying to eliminate 90% of the safety issues in C++?

If that is the manner in which you think a reasonable discussion can be had on this issue, then no, you are no qualified to discuss it and your participation has done nothing and continues to do nothing but derail the topic which is likely why no one has bothered responding to you.

The example given here is a different interpretation of a statement.

The source would stay the same for correct and incorrect use,there is no way for the compiler to catch this and send an error message.

It's certainly possible to make an expression of the form "bool > bool" a compiler error and require that developers rewrite it as "x && !y"

But they do break stuff.

I think the commitment is more that you can’t do anything to the language that would lead to some compiler hacker who also serves on the committee to have to remove their pet optimization, regardless of whether that optimization is worth much (or anything).

Goals and messaging matter. I like that the Rust community aims for safety as a P1 goal. C doesn’t, so C doesn’t get it.

> I don't know about this. There are a lot of people being paid by their companies to work on the C++ committee and on various compiler teams.

The standards document isn't the same as a C++ implementation. The implementations are actually behind the standards, at least given current contribution levels.

There are relatively few people making significant contributions to C and C++ in compilers. Funding for middle and backend features to compilers are a lot easier to justify and fund because it looks like more straightforward optimization payoffs.

A lot of the effort put into C++ implementation work goes to keeping up with the pile of features added to the C and C++ standards every three years or so.

Reply on news.ycombinator.com