Why is C++ so big?

C++ is not a tiny language designed to be a minimal language for teaching, but neither are the languages people most often compare it to, such as C, Java, C#. They too are huge compared to say, Pascal as Dr. Wirth originally defined it – for good reasons. The programming world is far more complex today than it was 30 years ago, and modern programming languages reflect that.

C++ isn’t as big as some people imagine. By word count, the size of the language specifications (excluding standard libraries) for C++, C#, and Java are currently within a few percentage points of each other. This reflects that they are general-purpose mainstream languages that have grown similar features – auto/var type deduction, range for loops, lambda functions, various levels of support for generic programming, and so on. It also reflects what design theorists call “essential complexity in the problem domain” – the complexity in the real world and that a serious language has to expose, everything from fundamental OS differences to calling C++ libraries.

In some cases C++ directly supports (i.e., in the language) what some other languages support through libraries, so the language part will be relatively larger. On the other hand, if you want to write a “typical modern application”, you need to consider operating system interfaces, GUI, databases, web interfaces, etc. the sum of language features, libraries, and programming conventions and standards that you must become familiar with dwarf the programming language. Here, C++’s size can be an advantage as far as it better supports good libraries.

Finally, the days where a novice programmer can know all of a language are gone, at least for the languages in widespread industrial use. Few people know “all of C” or “all of Java” either and none of those are novices. It follows that nobody should have to apologize for the fact that novices do not know all of C++. What you must do - in any language – is to pick a subset, get working writing code, and gradually learn more of the language, its libraries, and its tools. For my suggestion on how beginners can approach C++, see Programming: Principles and Practice using C++.

Who uses C++?

Lots and lots of companies and government sites. Lots. And if you’re using a compiler or runtime of another language, such as Java, chances are good that it too is implemented in C++.

There are too many C++ users to effectively count them, but the number is in the millions. C++ is supported by all major vendors. The large number of developers (and therefore the large amount of available support infrastructure including vendors, tools, training, etc.) is one of several critical features of C++.

During 1980-1991, the number of users doubled every seven and a half months (see The Design and Evolution of C++). The current growth rate is steady and positive. IDC’s 2001 estimate of the number of C++ programmers was “about 3 million”; their 2004 number was “more than 3 million.” That seems plausible and indicates a continued growth. Especially since about 2010 there is a renewed growth in C++ as both mobile and datacenter applications value “performance per Watt” as a new mainstream metric.

Why is portability considered so important?

Successful software is long-lived; life-spans of decades are not uncommon. A good application/program often outlives the hardware it was designed for, the operating system it was written for, the data base system it initially used, etc. Often, a good piece of software outlives the companies that supplied the basic technologies used to build it.

Often a successful application/program have customers/users who prefer a variety of platforms. The set of desirable platforms change as the user population changes. Being tied to a single platform or single vendor, limits the application/program’s potential use.

Obviously, complete platform independence is incompatible with the ability to use all platform specific facilities. However, you can often approximate platform independence for an application by accessing platform facilities through a “thin interface” representing the application’s view of its environment as a library.

Who is on the standardization committee?

The committee consists of a large number of people (about 200) out of whom about 100 turn up at the week-long meetings two or three times a year. In addition there are national standards groups and meetings in several countries. Most members contribute either by attending meetings, by taking part in email discussions, or by submitting papers for committee consideration. Most members have friends and colleagues who help them. From day #1, the committee has had members from many countries and at every meeting people from half a dozen to a dozen countries attend. The final votes are done by about 20 national standards bodies. Thus, the ISO C++ standardization is a fairly massive effort, not a small coherent group of people working to create a perfect language for “people just like themselves.” The standard is what this group of volunteers can agree on as being the best they can produce that all can live with.

Naturally, many (but not all) of these volunteers have day jobs focused on C++: They include compiler writers, tool builders, library writers, application builders, researchers, book authors, consultants, test-suite builders, and more.

Here is a very-partial list of some major organizations involved: Adobe, Apple, Boost, Bloomberg, EDG, Google, HP, IBM, Intel, Microsoft, Oracle, Red Hat.

Here is a short list of names of members who you may have encountered in the literature or on the web: Dave Abrahams, Matt Austern, Pete Becker, Hans Boehm, Steve Clamage, Lawrence Crowl, Beman Dawes, Francis Glassborow, Doug Gregor, Pablo Halpern, Howard Hinnant, Jaakko Jarvi, John Lakos, Alisdair Meredith, Jens Maurer, Jason Merrill, Sean Parent, P.J. Plauger, Tom Plum, Gabriel Dos Reis, Bjarne Stroustrup, Herb Sutter, David Vandevoorde, Michael Wong. Apologies to the 200+ current and past members that we couldn’t list. Also, please note the author lists on the various papers: a standard is written by (many) individuals, not by an anonymous committee.

You can get a better impression of the breath and depth of expertise involved by examining the authors listed in the WG21 papers archive, but please remember there are major contributors to the standards effort who do not write a lot.

What is the difference between C++98 and C++03?

From a programmer’s view there is none. The C++03 revision of the standard was a bug fix release for implementers to ensure greater consistency and portability. In particular, tutorial and reference material describing C++98 and C++03 can be used interchangeably by all except compiler writers and standards gurus.

What is the difference between C++98 and C++11?

Will be covered in detail in saperate section.

Note that the C++ language will remain stable because compatibility is always a major concern. The committee tries hard not to break your (standard conforming) code. Except for some corner cases you’re unlikely to notice, all valid C++98 code is valid C++11 and C++14 code.

What is the difference between C++11 and C++14?

Will be covered in separate section.

Note that the C++ language will remain stable because compatibility is always a major concern. The committee tries hard not to break your (standard conforming) code. Except for some corner cases you’re unlikely to notice, all valid C++98 code is valid C++14 code.

What are some “interview questions” I could ask that would let me know if candidates really know their stuff?

This answer is primarily for non-technical managers and HR folks who are trying to do a good job at interviewing C++ candidates. If you’re a C++ programmer about to be interviewed, and if you’re lurking in this FAQ hoping to know the questions they’ll ask you ahead of time so you can avoid having to really learn C++, shame on you: spend your time becoming technically competent and you won’t have to try to “cheat” your way through life!

Back to the non-technical manager / HR person: obviously you are eminently qualified to judge whether a candidate is a good “fit” with your company’s culture. However there are enough charlatans, wannabes, and posers out there that you really need to team up with someone who is technically competent in order to make sure the candidate has the right level of technical skill. A lot of companies have been burned by hiring nice but incompetent duds — people who were incompetent in spite of the fact that they knew the answers to a few obscure questions. The only way to smoke out the posers and wannabes is to get someone in with you who can ask penetrating technical questions. You have no hope whatsoever of doing that yourself. Even if I gave you a bunch of “tricky questions,” they wouldn’t smoke out the bad guys.

Your technical sidekick might not be (and often isn’t) qualified to judge the candidate on personality or soft skills, so please don’t abdicate your role as the final arbiter in the decision making process. But please don’t think you can ask a half dozen C++ questions and have the slightest clue if the candidate really knows what they’re talking about from a technical perspective.

Having said all that, if you’re technical enough to read the C++ FAQ, you can dig up a lot of good interview questions here. The FAQ has a lot of goodies that will separate the wheat from the chaff. The FAQ focuses on what programmers should do, as opposed to merely what the compiler will let them do. There are things that can be done in C++ but shouldn’t be done. The FAQ helps people separate those two.

What does the FAQ mean by “such and such is evil”?

It means such and such is something you should avoid most of the time, but not something you should avoid all the time. For example, you will end up using these “evil” things whenever they are “the least evil of the evil alternatives.” It’s a joke, okay? Don’t take it too seriously.

The real purpose of the term (“Ah ha,” I hear you saying, “there really is a hidden motive!”; you’re right: there is) is to shake new C++ programmers free from some of their old thinking. For example, C programmers who are new to C++ often use pointers, arrays and/or #define more than they should. The FAQ lists those as “evil” to give new C++ programmers a vigorous (and droll!) shove in the right direction. The goal of farcical things like “pointers are evil” is to convince new C++ programmers that C++ really isn’t “just like C except for those silly // comments.”

Now let’s get real here. I’m not suggesting macros or arrays or pointers are right up there with murder or kidnapping. Well, maybe pointers. (Just kidding!) So don’t get all hyper about the word “evil”: it’s supposed to sound a little outrageous. And don’t look for a technically precise definition of exactly when something is or isn’t “evil”: there isn’t one.

Items labeled as “evil” (macros, arrays, pointers, etc.) aren’t always bad in all situations. When they are the “least bad” of the alternatives, use them!

Will I sometimes use any so-called “evil” constructs?

Of course you will!

One size does not fit all. Stop. Right now, take out a fine-point marker and write on the inside of your glasses: Software Development Is Decision Making. “Think” is not a four-letter word. There are very few “never…” and “always…” rules in software — rules that you can apply without thinking — rules that always work in all situations in all markets — one-size-fits-all rules.

In plain English, you will have to make decisions, and the quality of your decisions will affect the business value of your software. Software development is not mostly about slavishly following rules; it is a matter of thinking and making tradeoffs and choosing. And sometimes you will have to choose between a bunch of bad options. When that happens, the best you can hope for is to choose the least bad of the alternatives, the lesser of the “evils.”

You will occasionally use approaches and techniques labeled as “evil.” If that makes you uncomfortable, mentally change the word “evil” to “frequently undesirable”