6 ms·

But that argument doesn't necessarily call for a new language, it only calls for the prohibition of the unsafe elements of the existing language. Intuitively on

But that argument doesn't necessarily call for a new language, it only calls for the prohibition of the unsafe elements of the existing language. Intuitively one might assume that potentially unsafe elements (like pointers, references, parts of the standard library, etc.) are so ingrained in C++ that prohibiting them would cripple the language. But actually, C++'s preprocessor is powerful enough that instead of abandoning those potentially unsafe elements, you can instead replace them with safe compatible substitutes. SaferCPlusPlus[1] is a collection of such substitutes. And since the substitute elements are themselves pure C++, you can still use your existing IDEs, debugging tools and SDKs. And the migration of existing code can be done completely incrementally, and much of it won't need to be changed at all. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus

pjmlp 10y ago
It doesn't work in the enterprise context where I am yet to see any code review taking place. The very few I happened to see weren't real ones, rather some meetings to tick a few check boxes, usually faded away after the managers realize the amount of "wasted money" doing them.
- duneroadrunner 10y ago
  You mean, that if there isn't some kind of (automated) enforcement, programmers will continue to "taint" code with unsafe elements? Yes, but just like one might anticipate the development of a good IDE/tool/libray/SDK ecosystem for Rust, you could imagine the development of a memory safety enforcement/verification tool for either SaferCPlusPlus or C++ in general. The C++ "Core Guidelines Lifetime Checker"[1] is intended to be such a tool for C++ in general. And such a tool for SaferCPlusPlus would be simple enough that, if it didn't want to wait for one, an enterprise could implement one itself. I mean, all it would have to do is identify any instances of potentially unsafe elements in the code. Right? Or are you suggesting that it would be "politically" unrealistic to impose a prohibition on unsafe C++ code in the enterprise context? So it would be more realistic to adopt a new language, like Rust, that doesn't have the baggage that C++ does? [1] https://blogs.msdn.microsoft.com/vcblog/2016/03/31/c-core-guidelines-checkers-preview-of-the-lifetime-safety-checker/ https://blogs.msdn.microsoft.com/vcblog/2016/03/31/c-core-gu...
  - pjmlp 10y ago
    I mean any form of review be it automated or manual. Money spent in code review processes and tooling is usually budgeted after unit testing and documentation, those tend to have quite small budgets and political willingness. Yes to your last question, the good thing about languages that aren't copy-paste compatible with C, is that there isn't any easy way to write code the C way.

pjmlp 10y ago

It doesn't work in the enterprise context where I am yet to see any code review taking place. The very few I happened to see weren't real ones, rather some meetings to tick a few check boxes, usually faded away after the managers realize the amount of "wasted money" doing them.

duneroadrunner 10y ago
You mean, that if there isn't some kind of (automated) enforcement, programmers will continue to "taint" code with unsafe elements? Yes, but just like one might anticipate the development of a good IDE/tool/libray/SDK ecosystem for Rust, you could imagine the development of a memory safety enforcement/verification tool for either SaferCPlusPlus or C++ in general. The C++ "Core Guidelines Lifetime Checker"[1] is intended to be such a tool for C++ in general. And such a tool for SaferCPlusPlus would be simple enough that, if it didn't want to wait for one, an enterprise could implement one itself. I mean, all it would have to do is identify any instances of potentially unsafe elements in the code. Right? Or are you suggesting that it would be "politically" unrealistic to impose a prohibition on unsafe C++ code in the enterprise context? So it would be more realistic to adopt a new language, like Rust, that doesn't have the baggage that C++ does? [1] https://blogs.msdn.microsoft.com/vcblog/2016/03/31/c-core-guidelines-checkers-preview-of-the-lifetime-safety-checker/ https://blogs.msdn.microsoft.com/vcblog/2016/03/31/c-core-gu...
- pjmlp 10y ago
  I mean any form of review be it automated or manual. Money spent in code review processes and tooling is usually budgeted after unit testing and documentation, those tend to have quite small budgets and political willingness. Yes to your last question, the good thing about languages that aren't copy-paste compatible with C, is that there isn't any easy way to write code the C way.