3 ms·
Because this would refuse to compile 100% of real-world C++ code, so nobody would use it. One problem is that C++ can directly include C headers of the operati
by the_why_of_y 6y ago
Because this would refuse to compile 100% of real-world C++ code, so nobody would use it.
One problem is that C++ can directly include C headers of the operating system, while languages that aren't copy-paste compatible with C have to create some kind of wrapper library for them... this is a major reason for the success of C++, but it also makes improvements of this kind far harder to deploy in practice.
- josteink 6y ago> Because this would refuse to compile 100% of real-world C++ code, so nobody would use it. So if anyone is claiming you could write real-world safe C++ if you wanted to, they are making a false claim then?
- the_why_of_y 6y agoI think you'd have to do the same thing that you'd do in non-C++ languages: write an abstraction layer that encapsulates the low-level OS access (or hardware access, in embedded software) and whose implementation is unsafe, but whose interface is "safe", whatever that means. Once you have that to build on top of, such a compiler flag could make sense... if it were possible in C++, which I'm not sure about. See for example this criticism of one such effort: https://robert.ocallahan.org/2016/06/safe-c-subset-is-vapourware.html https://robert.ocallahan.org/2016/06/safe-c-subset-is-vapour...
- josteink 6y agoSo in about half a decade the C++ camp has made no improvements wrt to tooling and statically verified safe code, it’s been all talk and no show. And in the meantime Rust has improved massively. It’s obviously still too early to declare a winner, but to me this sounds like a turtle slowly but surely overtaking a rabbit.