4 ms·

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 o

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.

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.