With all the new (and new-ish) languages out there, you might wonder why it’s still worth learning C++, a language first invented in 1983. Wedged amidst lower-level languages such as C, C++ went through a spike in popularity in the mid-‘90s, when developers realized it was easily translatable to assembly language; but today’s higher-level languages abstract the processor even further away. C++ has a lot in common with its parent, C; but C++ does a good bit more behind the scenes. Let’s talk about some of the anger towards C++ over that “behind the scenes” thing; you don’t have to look far to find someone who dislikes C++ specifically because of it. Check out the latest C++ jobs. Back in the early 1990s, I worked for a software company as a programmer. The company had recently moved from C to C++, and one of the senior developers was frustrated, complaining that calling member functions required a lookup table behind the scenes (he was referring to the virtual method table) rather than just a straight memory address; that really irked him because he felt it slowed the program down. (Even back then, the impact of the virtual method table was negligible in the applications we were building.) But perhaps the most famous rant against C++ came from none other than Linus Torvalds. It features some choice bits:

C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.

Torvalds had a problem with the library features of C++ such as STL and Boost, which he thinks are a.) unstable, and b.) inefficient, forcing developers to rewrite apps once they realize their code depends too much on the nice object models around it:

In other words, the only way to do good, efficient, and system-level and portable C++ ends up to limit yourself to all the things that are basically available in C. And limiting your project to C means that people don't screw that up, and also means that you get a lot of programmers that do actually understand low-level issues and don't screw things up with any idiotic "object model" crap.

Tell us how you really feel, Linus. There are plenty of rebuttals to his attack, but I'll just make two points. First, he obviously knows his stuff. Second, C does have its place… if you're writing systems-level code that you want as tight and portable as possible. That latter concern aside, though, this is the 21st century: Why write dozens of lines of code when a single line of code (as with C++) will do it? A multitude of companies believe the benefits of C++ outweigh the drawbacks; although higher-level languages such as Python and C# have really taken off, there are still lots of C++ jobs; it’s not going away anytime soon. Supporters argue that C++ provides a fine mix of C’s low-level aspects (looking at the compiled assembly code, etc.) while providing higher-level attributes found in today’s modern languages. Early in its development, C++ featured a standard template library (STL) with template classes such as vectors and maps, which allows for a certain level of generic programming. The STL allowed programmers to focus on applications-level tasks without having to write their own linked lists and other data structures every time. But such functionality must be used responsibly. I've witnessed a lot of “over-engineering” in my life, wherein people would write reusable classes with several layers of inheritance, even though the reusable class wasn’t actually used more than once; worse, that sort of behavior can result in massive libraries of classes nearly impossible to debug. But I would argue that’s the exception, not the norm; when done right, generic programming and other high-level aspects of C++ can provide enormous benefits.

Along Came C++11

Fifteen or so years ago, as languages such as JavaScript and Python became more popular, programmers began to embrace techniques and styles that, while not new, were easily available in those languages. Meanwhile, a group of C++ experts began putting together a library called Boost, which pushed the features of C++ to the limits, giving programmers access to the techniques commonly used in other, newer languages. Many of the creators of Boost were on the C++ Standards Committee, and some of the Boost features have found their way into the latest official incarnation of C++, called C++11. Keeping with our theme here, C++11 does even more “behind the scenes” than its predecessors. But that’s not a bad thing, depending on how you use it; for example, C++11 now offers lambda functions as an official part of the language. Lambda functions in C++ have a strange-yet-expressive syntax that might take some getting used to, as you can see in this example (which barely scratches the surface of C++ lambdas):

auto myfunc = []() { cout << "Greetings from the lambda" << endl; };

This creates a function and stores it in a variable called myfunc. (The concept of storing a function in a variable is familiar to programmers in other languages such as JavaScript.) You can use lambda functions in places where you previously might have used function pointers. Yes, they do a lot behind the scenes, but they also hold great potential. Systems-level programming probably still needs C, but for high-level applications, C++ is a great choice. And judging by the number of C++ jobs today, the language is not going away anytime soon. Now is still a great time to learn this older programming language; don't let the famous naysayers and their profane soliloquies about inelegance dissuade you. Image: Gajus/Shutterstock.com