The elephant is this: C++ is an extremely complex programming language.
Let me first work to support this claim. In other words, is there evidence that C++ is an extremely complex programming language?
In a talk he gave in 2010 at the O’Reilly Open Source Conference, Pike made his case against such “industrial programming languages” during his keynote at the conference. Quoting from that keynote:
“I think these languages are too hard to use, too subtle, too intricate. They’re far too verbose and their subtlety, intricacy and verbosity seem to be increasing over time,” Pike said. “They’re oversold, and used far too broadly.”
There are times when C++ can be too verbose, but that’s not the most serious problem. In my experience, the most serious problem is the difficulty journey-level engineers have in using the language safely and confidently. It is an extremely subtle and intricate language; it’s easy to do fail to understand some corner-case, with the result being a surprising error at run-time, or, more often, a great deal of time is wasted by people who are both very expensive and somewhat unclear on exactly what their C++ code actually means.
If you work with C++ developers, you may be able to verify this yourself. Get a few of them together in a group and ask them to explain the pros and cons of C++ move semantics, which were introduced in C++11. As they discuss the topic, see if you can determine whether they are speaking confidently, and whether everything is obvious to them, or whether they are perhaps somewhat less than confident in their grasp of the subject matter.
I don’t wish to beat a dead horse, but there is also this thread by Linus Torvalds to be considered. Linus Torvalds is the primary author for the Linux operating system. It’s an incredibly successful open source operating system that is used, well, everywhere, today.
C++ is not one language, but several, if you consider the significant revisions that have occurred over the years. There is an ISO standard for the language – International Standard ISO/IEC 14882:2012(E) – Programming Language C++. You can purchase a copy of the standard for about $60.00, but you will be in for a lot of reading. The standard is a well-written but complex technical document. It is not light reading and runs to 1,356 pages in length.
The last points I will make are these. First, there is a whole industry devoted to building tools to help C++ programmers find subtle errors in their code. Second, my own experience of 20 years of developing code in C++ has taught me that most people in any development shop are not language lawyers. They learn the language well enough to get along, and to fit in to the tribe, but they never learn the language well enough to be able to avoid being periodically surprised by some aspect of it. I understand why this happens – there is going to be variation in every group – but it’s a problem when your developers aren’t in full intellectual control of the language they are using to write the code that is going to be running on the medical device you intend to ship.
At this point, it might seem as if I am against the use of C++ for the development of safety-critical, embedded systems. I am not. C++ can be used, safely and well, in such contexts. But it’s not a triviality and it doesn’t happen without a concerted and continued effort to realize it.
If you are going to use C++ in the development of such systems, you must have a full, conscious, objective and shared understanding of exactly what you are signing up for. There are many, many things you can do to ensure that your C++ development proceeds at an effective rate, while at the same time ensuring that the product you develop is safe and effective (or, in more modern parlance, meets its essential performance requirements.)
As just one example of what can be done, let me suggest the following.
In any development group of more than a few individuals, you are almost certain to have one or two people who could serve as the language lawyers for the group. Allow them to participate in setting the standards for code development in your group. Then verify that what they advocate is actually good practice – perhaps invite some outside experts to review your code base and SOPs. The language lawyers should be working from one or more of the well-known books from individuals like Herb Sutter, Scott Meyers and other recognized experts. Believe me, these people earn tens of thousands of dollars every time they address a group of developers. Your language lawyers should be reusing their carefully-considered and vetted recommendations.
Once you have adopted and established standards for good practice within your development group, you’ll be much less likely to get into trouble. That being said, the development of safety-critical embedded systems in C++ will likely never be easy.