A Critique of C++

The title of this Web page is somewhat misleading. This web page consists of my brief rant on C++ and a link to Ian Joyner's far more complete analysis of C++: C++??: A Critique of C++

I have been using C++ for many years. I've been using C++ almost exclusively since 1996 (although I have started to use Java for some applications). I have developed tens of thousands of lines of new code and maintained this code in a released product. A number of fairly sizable examples of my C++ code are published on bearcave.com. My experience with C++ over these years has given me a love/hate relationship with the language. I would certainly rather use C++ than C. Even when performance is not an issue, I've chosen to use C++ over Java in some cases. I love C++ because it allows me to build complex software systems at a more abstract level than I could in C. I hate the language because of its seemingly endless complexity and seductive features (e.g., templates) which can lead into swamps of unmanageable complexity (just try debugging a deeply nested template). The size of the C++ language also guarantees that no two implementations will exactly match (see the discussion about portability on my String container web page). C++ code is much less portable than C code (just try porting code between Windows, Solaris, A/IX and HP/UX).

C++ has a long history. The language started out as an experiment in object oriented programming based on C. A front end translator read this ancestor version of C++ and generated C. This front end translator and its limitations affected the language, as did the design objective that C++ be as backward compatible with C as possible. Once C++ started to catch on these evolutionary features were joined by design by committee, which gave us features like dynamic_cast and the Standard Template Library (STL). It is interesting to contrast C++ with Java, which was never designed to be compatible with C (but rather is C based).

A programming language should support the expression of algorithms. It should aid the programmer, not stand in their way. The end result of the evolution of C++ is a language that forces the programmer to be constantly concerned with language features like constructors, destructors and copy constructors. The complex interactions of namespaces, header files, templates and static variable can take years to master. Complete documentation of complex C++ constructs requires that the programmer document not only the algorithm, but also the language feature, since the reader may not be familiar with all of the dark corners of this baroque language.

Developing large software systems in C++ is like swimming across a lake with a ten kilogram weight strapped to your waist. If you are a strong swimmer you can succeed at the task, but it would have been easier without that damn weight.

The idea that C++ is not unconditionally wonderful seems fairly radical. Almost as radical as the concept that object oriented design is not the solution to all of our software engineering difficulties. (Good object oriented design is the solution and good design is hard, which is something that some managers don't want to hear.) It's even possible that loudly proclaiming such heresy will damage one's chances of employment.

Whenever there are such dogmatic views, another view is good for balance. In his essay C++??: A Critique of C++. Ian Joyner provides an indepth analysis of C++. In this essay he writes

The [software] industry needs less hype and more sensible programming practices

After seeing over twenty years of hype and fads (can you say "Extreme Programming") I find this hard to argue with. Programming languages are tools for engineering and computer science. Lets consider them in that light and leave the Kool Aid undrunk.

Ian Joyner is a proponent of the Eiffel programming language. Eiffel may, as he suggests, have much of the power of C++ without most of the pitfalls. But there will never be a single programming language that is equally optimal for all applications.

Compiler supported garbage collection (in Java, for example) makes software much easier to develop, since it frees the programmer from constantly worrying about memory allocation. However, garbage collection is of questionable value in a real-time embedded system. Generic classes (which C++ templates attempt to implement) are a powerful concept. Operator overloading is useful in many cases. However, these features introduce language complexity. There is a real danger that if generics and operator overloading is added to Java, its complexity will start to approach that of C++.

While I don't have any answers for programming language nirvana, I think that I can safely state that C++ is not it.

Ian Kaplan, March 5, 2000
Revised: May 2002

back to Miscellaneous Technical Topics

back to home page