6 ms·

Safe by convention is a ridiculous notion. I think (and I know this isn't a popular opinion here, but I'll say it anyway) that C and C++ are dying horses; thes

Safe by convention is a ridiculous notion. I think (and I know this isn't a popular opinion here, but I'll say it anyway) that C and C++ are dying horses; these 'modern' versions and 'best practices' are not adequate solutions, evidenced partly by the fact that we can't even agree on what they should be. The next decade is going to see the rise of systems programming languages with static safety guarantees. Personally, I think Rust has a lot of potential, but we will see.

72deluxe 11y ago
C++ has had to be backwards compatible for the billions of lines of code written in it. It has managed to introduce new features and safety quite well in view of this. Perhaps the rise of systems programming languages with static safety guarantees is C++ already? You don't have to write it with "old school" methodology just because you can write it with old-school dangerous approaches. I think that C++11 and beyond will do quite well. Sadly here in the UK at least, it has lost vast swathes of the job market to C# (likely because of C++11 taking so long to appear) but there are still a few C++ jobs (for maintaining crusty MFC codebases) or a few that specifically mention C++11. I myself think C++11 is a great language and daily write C++03 at work through gritted teeth. As you say though, we'll see what comes about. It is only a language after all. EDIT: And I will add that C++ does have the benefit of having loads of libraries available to it, including GUI libraries and bindings which makes development a breeze.
- lmm 11y ago
  > C++ has had to be backwards compatible for the billions of lines of code written in it. It has managed to introduce new features and safety quite well in view of this. Perhaps the rise of systems programming languages with static safety guarantees is C++ already? You don't have to write it with "old school" methodology just because you can write it with old-school dangerous approaches. The very definition of static safety guarantees is that the compiler enforces them, and that's what makes them useful. C++ has great safety guarantees if written correctly - but if you can reliably write code correctly, you don't need safety guarantees in the first place! > EDIT: And I will add that C++ does have the benefit of having loads of libraries available to it, including GUI libraries and bindings which makes development a breeze. There are many libraries, but the important ones have mature bindings from other languages, or at least tools for generating them (e.g. Swig). That said, using them exposes you to the safety risks of C++, so you're often better off rewriting them (e.g. I worked on a Java project that initially used ffmpeg to handle some transcoding tasks - but as a result had to deal with bugs in ffmpeg that took down the whole JVM for particular inputs).
  - 72deluxe 11y ago
    The safety guarantees being enforced by the compiler does mean that you can (and really should) offload all the checking onto the compiler and not think you know better by casting everywhere etc. Good point though! Sad about your JVM - did you not monitor the state of the process you spawned to handle transcoding? Did you end up fixing the bugs in ffmpeg?
    - lmm 11y ago
      > The safety guarantees being enforced by the compiler does mean that you can (and really should) offload all the checking onto the compiler and not think you know better by casting everywhere etc. When the set of actions that might violate the guarantees is small, circumscribed and easy to spot in code review and/or with automated tools this kind of approach works. But in C++ it feels more like today's best practices are tomorrow's unsafe constructs - it's like perl's "there is more than one way to do it", but additionally all but one of the ways are unsafe. > did you not monitor the state of the process you spawned to handle transcoding? That was my point - we originally tried to use JNI so that we could use libffmpeg as a library (and e.g. handle parameters and input/output as structured data rather than having to flatten them to a string command line and temporary file or pipe). But unfortunately if you do that you give up the nice guarantees of the JVM platform - e.g. a Java-native library will only ever affect its own thread, but a bug in a JNI library can take down the whole JVM. (We did ultimately move to a separate-process-for-transcoding model for exactly this reason) > Did you end up fixing the bugs in ffmpeg? We fixed specific bugs as we found them. It didn't feel like we were making a dent in the number there were though.
  - zanny 11y ago
    It would be neat though if GCC and Clang supported some compiler flag like Wsafe to warning on all raw pointer manipulation and raw memory addressing. Would make maintaining a C++ project and avoiding unsafe habits easier.
steveklabnik 11y ago
I am actually re-writing Rust's documentation on ownership right now. I'm interested to compare and contrast my stuff with this. (First draft of the first chapter is https://github.com/rust-lang/book/pull/58 https://github.com/rust-lang/book/pull/58, I have PRs up for the other two, but they're not quite as polished yet)
cousin_it 11y ago
I wanted to write a similar comment, but then noticed that the paper claims 100% safety by using an analysis tool, not just by convention. Agreed about the potential of Rust, it sidesteps most of these problems. Though it might introduce other problems of its own, only time will tell. I expect that Rust's future sore spots will include destructor leaks, the reliance on macros, and the tremendous complexity of traits. (Though of course I don't claim to have better solutions to those.)
- kibwen 11y ago
  > destructor leaks Rust doesn't leak destructors any more than C++ (including the version of C++ presented in the OP). The only way to leak a destructor accidentally is to create a cycle (which is quite difficult to do, essentially requiring you to stuff a RefCell inside an Rc) or to have some data owned by a thread that's eternally stalled. > reliance on macros Individual macros are generally regarded as convenient workarounds rather than ideal long-term solutions, and anywhere that you see pervasive macro use tends to be ripe for an RFC for a dedicated feature to subsume it. > the tremendous complexity of traits No denying that traits are Rust's "deepest" feature, but that's because of a general philosophy to leverage traits to provide newly desired bits of functionality rather than introducing all-new language concepts. Removing functionality from traits wouldn't result in making the language less complex; that functionality would just end up going elsewhere.
  - kbenson 11y ago
    > Removing functionality from traits wouldn't result in making the language less complex; that functionality would just end up going elsewhere. Yes, the Waterbed Theory of Complexity[1]. It can be useful to funnel complexity into specific areas where it's at least expected, and there may exist better mechanisms for dealing with it. 1: https://en.wikipedia.org/wiki/Waterbed_theory https://en.wikipedia.org/wiki/Waterbed_theory
  - cousin_it 11y ago
    > destructor leaks Right, I'm not saying C++ is perfect either. I feel like Rust made a wrong turn here: https://www.reddit.com/r/rust/comments/3404ml/prepooping_your_pants_with_rust/ https://www.reddit.com/r/rust/comments/3404ml/prepooping_you... > reliance on macros I'm referring specifically to try!.
gpderetta 11y ago
The paper is not arguing for safe 'conventions'. It describes a (sketch of) a statically provable memory safe dialect of c++. A more detailed description is in one of the referenced papers by Herb Sutter. Unfortunately the promised static checker is, as far as I know, yet to be released, and we will have to see how well it will work in practice and whether it is feasible to piecemeal add the safety annotations to an existing codebase.
krylon 11y ago
In the long run, I agree with you, where new projects are concerned. At the same time, we have these mountains of C/C++ around that aren't going to go anywhere anytime too soon. Remember the Y2K problem and how those programmers in the 60s and 70s thought that by the year 2000, surely their code would have been either fixed or rewritten. At most, C and C++ are "dying" in the same way COBOL is - for new projects, other languages might prevail, but there are still mountains of legacy code written in it that nobody dares touch...

72deluxe 11y ago

C++ has had to be backwards compatible for the billions of lines of code written in it. It has managed to introduce new features and safety quite well in view of this. Perhaps the rise of systems programming languages with static safety guarantees is C++ already? You don't have to write it with "old school" methodology just because you can write it with old-school dangerous approaches. I think that C++11 and beyond will do quite well. Sadly here in the UK at least, it has lost vast swathes of the job market to C# (likely because of C++11 taking so long to appear) but there are still a few C++ jobs (for maintaining crusty MFC codebases) or a few that specifically mention C++11. I myself think C++11 is a great language and daily write C++03 at work through gritted teeth. As you say though, we'll see what comes about. It is only a language after all. EDIT: And I will add that C++ does have the benefit of having loads of libraries available to it, including GUI libraries and bindings which makes development a breeze.

lmm 11y ago
> C++ has had to be backwards compatible for the billions of lines of code written in it. It has managed to introduce new features and safety quite well in view of this. Perhaps the rise of systems programming languages with static safety guarantees is C++ already? You don't have to write it with "old school" methodology just because you can write it with old-school dangerous approaches. The very definition of static safety guarantees is that the compiler enforces them, and that's what makes them useful. C++ has great safety guarantees if written correctly - but if you can reliably write code correctly, you don't need safety guarantees in the first place! > EDIT: And I will add that C++ does have the benefit of having loads of libraries available to it, including GUI libraries and bindings which makes development a breeze. There are many libraries, but the important ones have mature bindings from other languages, or at least tools for generating them (e.g. Swig). That said, using them exposes you to the safety risks of C++, so you're often better off rewriting them (e.g. I worked on a Java project that initially used ffmpeg to handle some transcoding tasks - but as a result had to deal with bugs in ffmpeg that took down the whole JVM for particular inputs).
- 72deluxe 11y ago
  The safety guarantees being enforced by the compiler does mean that you can (and really should) offload all the checking onto the compiler and not think you know better by casting everywhere etc. Good point though! Sad about your JVM - did you not monitor the state of the process you spawned to handle transcoding? Did you end up fixing the bugs in ffmpeg?
  - lmm 11y ago
    > The safety guarantees being enforced by the compiler does mean that you can (and really should) offload all the checking onto the compiler and not think you know better by casting everywhere etc. When the set of actions that might violate the guarantees is small, circumscribed and easy to spot in code review and/or with automated tools this kind of approach works. But in C++ it feels more like today's best practices are tomorrow's unsafe constructs - it's like perl's "there is more than one way to do it", but additionally all but one of the ways are unsafe. > did you not monitor the state of the process you spawned to handle transcoding? That was my point - we originally tried to use JNI so that we could use libffmpeg as a library (and e.g. handle parameters and input/output as structured data rather than having to flatten them to a string command line and temporary file or pipe). But unfortunately if you do that you give up the nice guarantees of the JVM platform - e.g. a Java-native library will only ever affect its own thread, but a bug in a JNI library can take down the whole JVM. (We did ultimately move to a separate-process-for-transcoding model for exactly this reason) > Did you end up fixing the bugs in ffmpeg? We fixed specific bugs as we found them. It didn't feel like we were making a dent in the number there were though.
- zanny 11y ago
  It would be neat though if GCC and Clang supported some compiler flag like Wsafe to warning on all raw pointer manipulation and raw memory addressing. Would make maintaining a C++ project and avoiding unsafe habits easier.

steveklabnik 11y ago

I am actually re-writing Rust's documentation on ownership right now. I'm interested to compare and contrast my stuff with this. (First draft of the first chapter is https://github.com/rust-lang/book/pull/58 https://github.com/rust-lang/book/pull/58, I have PRs up for the other two, but they're not quite as polished yet)

cousin_it 11y ago

I wanted to write a similar comment, but then noticed that the paper claims 100% safety by using an analysis tool, not just by convention. Agreed about the potential of Rust, it sidesteps most of these problems. Though it might introduce other problems of its own, only time will tell. I expect that Rust's future sore spots will include destructor leaks, the reliance on macros, and the tremendous complexity of traits. (Though of course I don't claim to have better solutions to those.)

kibwen 11y ago
> destructor leaks Rust doesn't leak destructors any more than C++ (including the version of C++ presented in the OP). The only way to leak a destructor accidentally is to create a cycle (which is quite difficult to do, essentially requiring you to stuff a RefCell inside an Rc) or to have some data owned by a thread that's eternally stalled. > reliance on macros Individual macros are generally regarded as convenient workarounds rather than ideal long-term solutions, and anywhere that you see pervasive macro use tends to be ripe for an RFC for a dedicated feature to subsume it. > the tremendous complexity of traits No denying that traits are Rust's "deepest" feature, but that's because of a general philosophy to leverage traits to provide newly desired bits of functionality rather than introducing all-new language concepts. Removing functionality from traits wouldn't result in making the language less complex; that functionality would just end up going elsewhere.
- kbenson 11y ago
  > Removing functionality from traits wouldn't result in making the language less complex; that functionality would just end up going elsewhere. Yes, the Waterbed Theory of Complexity[1]. It can be useful to funnel complexity into specific areas where it's at least expected, and there may exist better mechanisms for dealing with it. 1: https://en.wikipedia.org/wiki/Waterbed_theory https://en.wikipedia.org/wiki/Waterbed_theory
- cousin_it 11y ago
  > destructor leaks Right, I'm not saying C++ is perfect either. I feel like Rust made a wrong turn here: https://www.reddit.com/r/rust/comments/3404ml/prepooping_your_pants_with_rust/ https://www.reddit.com/r/rust/comments/3404ml/prepooping_you... > reliance on macros I'm referring specifically to try!.

gpderetta 11y ago

The paper is not arguing for safe 'conventions'. It describes a (sketch of) a statically provable memory safe dialect of c++. A more detailed description is in one of the referenced papers by Herb Sutter. Unfortunately the promised static checker is, as far as I know, yet to be released, and we will have to see how well it will work in practice and whether it is feasible to piecemeal add the safety annotations to an existing codebase.

krylon 11y ago

In the long run, I agree with you, where new projects are concerned. At the same time, we have these mountains of C/C++ around that aren't going to go anywhere anytime too soon. Remember the Y2K problem and how those programmers in the 60s and 70s thought that by the year 2000, surely their code would have been either fixed or rewritten. At most, C and C++ are "dying" in the same way COBOL is - for new projects, other languages might prevail, but there are still mountains of legacy code written in it that nobody dares touch...