It isn't surprising to find the creator of a language defending the language they created and so it is with the latest paper from Bjarne Stroustrup. Is it fair for the NSA to tell programmers to stay away from C and C++ and prefer C#, Go, Java Ruby and Swift?

I also guess in the background here is the rise of Rust as a safe alternative to C/C++. Safe here specifically means memory safe which is quite reasonable as the majority of problems and vulnerabilities are memory related rather than logic related. 

What has upset Stroustrup so much is a report on Software Memory Safety from the NSA (National Security Agency) which states: 

"the overarching software community across the private sector, academia, and the U.S. Government have begun initiatives to drive the culture of software development towards utilizing memory safe languages."

Stroustrup claims that this point of view was reached without any C++ experts being involved and so the software community was hardly inclusive. Of course. we all have a tendency to defend the language we have invested time and expertise in, but even though I have been programming in C and occasionally C++ for a long time and hence have a lot invested, I recognize that C is a language that has memory problems. All you have to do is return a pointer to a local variable or to something on the heap and you have a problem. The only way to deal with these difficulties is to be aware of them and program defensively. This is moderately easy in C, but I find much more difficult in C++. The reason is that C++ is a much more complex language and there are so many ways of using it that you can easily miss the conditions for a memory leak. As a result I think that C++ is more dangerous to work in than C, but I know people who would argue the opposite and Stroustrup is one of them:

" ...specifically and explicitly excludes C and C++ as unsafe. As is far too common, it lumps C and C++ into the single category C/C++, ignoring 30+ years of progress. Unfortunately, much C++ use is also stuck in the distant past, ignoring improvements, including ways of dramatically improving safety."

In my opinion the additions that improve safety are part of the problem as they just make C++ even more difficult to fathom and increase the number of styles that C++ can be written in. As I have commented in the past after reading a book or almost anything by Stroustrup I'm convinced that C++ is the cleanest safest language on the planet, but as soon as I move out of his influence it all degenerates. Is a language that needs static analysis and very skilled and vigilant programmers to be safe worth calling safe?

I think that there is a case for making C++ safer by making it depend on tools that guide how it is used so strongly that they make it a different language. This of course raises the question of how the existing code base would be treated?

Is C unsafe? - Of course it is and it's part of the reason we want to use it. The lower-level of abstraction is what makes C a useful language and we have to accept that at this level we are responsible for all that goes wrong.

Is C++ unsafe? As much if not more so than C and it really isn't the reason we want to use it. You move to C++ because you want to abstract yourself away from the reality of the machine to build objects and type systems. There really is no reason to limit this sophistication and avoid memory management.

More Information

A call to action: Think seriously about “safety”; then do something sensible about it

Software Memory Safety

Related Articles

C++ Is TIOBE's Language Of The Year

Bjarne Stroustrup On Why Learn C++

Bjarne Stroustrup Thinks He Has A Better Way To Do Generics

Learn C++ With Udacity 

In Praise Of C++ - Bjarne At ICPC 2013

Google's Carbon Is Trying To Be A Better C++

To be informed about new articles on I Programmer, sign up for our weekly newsletter, subscribe to the RSS feed and follow us on Twitter, Facebook or Linkedin.

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info