3 ms·

> It only works when everyone plays balls and doesn't do C style coding, ever. If that’s the problem, and solving that would solve all of C++s memory-issues, w

> It only works when everyone plays balls and doesn't do C style coding, ever. If that’s the problem, and solving that would solve all of C++s memory-issues, why have no-one made a compiler option to simply make that code illegal? A -EUNSAFE or whatever?

pjmlp 6y ago
Because what got C++ adopted in first place was its copy-paste compatibility with C. C++ was also born at Bell Labs, and due to that, all major C compiler vendors quickly started shipping C++ on their boxes as well. If you take away copy-paste compatibility you might be better off doing D, C# or whatever safe variant already exists. Which is what many of us have done, to move to type safe languages, and only use C and C++ at the boundaries, in small pockets of unsafe code. In fact if you look at mobile OSes, that is the reality for app developers, C and C++ are no longer the full stack languages they were 20 years ago, rather used for the kernel, drivers, compositor and shading languages, but everything else happens in safer languages. And the SDKs only allow you to write libraries, not full applications. Naturally are clever developers that subvert the workflow and transform the libraries into the actual application.
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 ago
    I 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 ago
      So 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.
anlp1kk 6y ago
Because you would make many proven algorithms from Knuth or CLRS illegal. This is never acknowledged by the C++ people: Idiomatic C++ is not suitable for formal proofs, if you don't believe me, ask Xavier Leroy.

pjmlp 6y ago

Because what got C++ adopted in first place was its copy-paste compatibility with C. C++ was also born at Bell Labs, and due to that, all major C compiler vendors quickly started shipping C++ on their boxes as well. If you take away copy-paste compatibility you might be better off doing D, C# or whatever safe variant already exists. Which is what many of us have done, to move to type safe languages, and only use C and C++ at the boundaries, in small pockets of unsafe code. In fact if you look at mobile OSes, that is the reality for app developers, C and C++ are no longer the full stack languages they were 20 years ago, rather used for the kernel, drivers, compositor and shading languages, but everything else happens in safer languages. And the SDKs only allow you to write libraries, not full applications. Naturally are clever developers that subvert the workflow and transform the libraries into the actual application.

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 ago
  I 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 ago
    So 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.

anlp1kk 6y ago

Because you would make many proven algorithms from Knuth or CLRS illegal. This is never acknowledged by the C++ people: Idiomatic C++ is not suitable for formal proofs, if you don't believe me, ask Xavier Leroy.