4 ms·

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 var

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

nindalf 3y ago
> 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 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.
- soulbadguy 3y ago
  > it's just that in practice the C++ community has always chosen performance over any other concern (https://research.swtch.com/ub 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.

nindalf 3y ago

> 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 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.

soulbadguy 3y ago
> it's just that in practice the C++ community has always chosen performance over any other concern (https://research.swtch.com/ub 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.