This chapter is from the book
This chapter is from the book
This chapter is from the book
2.2 How Much + in C++?
My name is Ozymandias, King of Kings
Look on my Works, ye Mighty, and despair!
“Ozymandias,”
Percy Bysshe Shelley
The language wars are never ending, and in the following letter KV was perhaps baited into bashing one such language. To be honest I’ve always hated C++; I find it bloated and that it mostly produces intractable mounds of horse$#!+, as my grandmother used to say, which are hard to maintain and hard to tune. My response here is probably a bit tamer than my true feelings on C++, in part because I know that people will choose what they choose and also that we’re all dealing with a mound of technical debt that we often didn’t start with but that was thrust upon us on day one at work. That there are schools that still think that C++ is a good language to start teaching computer science with is, quite frankly, maddening, and I wish they would stop. I consider that particular practice to be mental health abuse. It would be better to give the students Python than C++, or, perhaps, an assembler.
In the years since this letter and response were first published we find that there are at least two new contenders in the compiled language space, Rust and Go. KV has only a passing acquaintance with both of these but is excited to see Rust trying to push into the embedded space, in particular. A language with better memory safety in systems that often lack virtual memory protections seems like it ought to be a good thing for every koder’s mental health. The other upside with both Rust and Go is that they look somewhat familiar to those of us who already program in the Algol-like languages, so a jump from, say, C, C++, or Java to either of these languages isn’t going to cause so much cognitive dissonance that you feel as if you’d put a small piece of blotter paper under your tongue before starting to work. As for either of these new languages as a teaching language, the jury is very definitely still out, and I still prefer we teach students with something interactive to start, such as Python.
For now let’s see just how much + KV was able to find in C++.
Hello KV,
Since there was some debate in my company over this issue, I’m curious to see what do you believe: putting aside performance issues (which I think are relatively minor on modern PCs), when would you recommend using C++ for development, and when would you recommend C? Do you think it is always better to use C++?
My feeling is that unless your application is inherently object-oriented (e.g., user interfaces), C++ will tend to make the implementation worse instead of making it better (e.g., constructors and operators doing funny unexpected things, C++ experts trying to ”use their expertise” and writing C++ code that is very efficient but extremely hard to read and even not portable, huge portability and performance issues when using templates, incomprehensible compiler/linker error messages, etc., etc.). I also think that while people can write bad C code (gotos out of macros was a nice one), typically people can write awful C++ code.
So, what do you think, where do you stand on this dispute?
Wondering How Much + There Is in ++
Dear Wondering,
Picking a language is something I’ve addressed before in other letters, but the C vs. C++ debate has raged as long as the two languages have been in existence, and really, it’s getting a bit tiring. I mean, we all know that assembler is the language that all red-blooded programmers write in! Oh, no wait, that’s not it.
I’m glad you ask this question, though, because it gives me license to rant about it and also to dispel a few myths.
The first and most obvious myth in your letter is that user interfaces are inherently object-oriented. While many introductory textbooks on object-oriented programming have user interfaces as their examples, this has a lot more to do with the fact that humans like pretty pictures. It is far easier to make a point graphically than with text. I have worked on object-oriented device drivers, which are about as far as you’ll ever get from a user interface.
Another myth that your letter could promulgate is that C is not an object-oriented language. A good example of object-oriented software in C is the vnode filesystem interface in BSD Unix and other operating systems. So, if you want to write a piece of object-oriented software, you can certainly do it in C or C++, or assembler for that matter.
One final myth, which was actually dispelled by Donn Seely in ”How Not To Write FORTRAN in any Language” (ACM Queue vol. 2, no. 9 - Dec/Jan 2004–2005), is that C++ leads to less understandable code than C. Over the past 20 years I have seen C code that was spaghetti and C++ code that was a joy to work on, and vice versa.
So, after all that myth bashing, what are we left with? Well, the things that are truly important in picking a language are:
1) What language is the largest percentage of the team experienced in?
If you’re working with a team and six out of eight of them are well-versed in C but only two know C++, then you’re putting your project, and job, at risk in picking C++. Perhaps the two C++ koders can teach the C folks enough C++ to be effective, but it’s unlikely. In order to estimate the amount of work necessary for a task you have to understand your tools. If you don’t normally use a nail gun, then you’re likely to take someone’s toe off with it. Losing toes is bad as you need them for balance.
2) Does the application require any of the features of the language you’re using?
C and C++ are a lot alike as languages, i.e., in syntax, but they have different libraries of functions and different ways of working that may or may not be relevant to your application. Often real-time constraints require the use of C because of the control that can be gotten over the data types. If type safety is of paramount importance, then C++ is a better choice because that is a native part of the language that is not present in C.
3) Does the application require services from other applications or libraries that are hard to use or debug from one or the other language?
Creating shim layers between your code and the libraries you depend on is just another way of adding useless, and probably buggy, code to your system. Shim layers should be avoided like in-laws. They’re OK to talk about, and you might consider keeping them around for a week, but after that, out they go as so much excess, noisy baggage.
There are lots of other reasons to choose one language over another, but I suspect that the three listed should be enough for you and your team to come to some agreement, and you’ll notice that none of them had to do with how easy it is to understand templates or how hard it is to debug with exceptions.
KV