C++98 and the First ISO Standard

Standards for widely used languages do not appear on a fixed schedule. C++11 is the current version of C++ at the time of its ratification, and it was developed over a long period by the members of the standards committee known as WG21. Before looking at what C++11 contains, it helps to understand why the work took as long as it did. The answer has three parts: how the committee chose to operate, the growing size of modern languages, and a belief about ISO rules that turned out to be wrong.

Keep in mind that this version of the language was known for years as C++0x. That working name reflected the hope that the standard would finish within the current decade. The name changed, but the standard it refers to is the same document: C++11.

As you read the timeline and the growth figures below, keep one question in mind: if you were on the committee, what would you have needed in order to finish sooner, and what would you have risked by hurrying?

The path to C++11 can be traced through three anchor points. Serious feature work on the language began in 2002. An initial draft standard was produced for public review in 2009. The second ISO C++ standard, identified as ISO/IEC 14882:2011, was then ratified by a 21-0 national vote in August 2011.

Notice two details in the final milestone. The vote was a national vote, and the document it ratified was formally the second ISO C++ standard. The first milestone, the start of serious feature work, is the one that matters most for understanding the gap, because the years before it were not spent on new features.

Many people assume that a standards body must pause after publishing a standard, waiting a set period before it can begin designing the next round of features. Members of the C++ committee held this same impression about the ISO rules. Read carefully, the situation is more specific than that. The committee believed a waiting period was required. That belief was mistaken, and it still affected the timeline.

Once the premise is corrected, the consequence becomes clear. The committee was not forced to sit idle after the earlier standard. It chose to delay serious feature work on the strength of a rule it misread. That delay is one reason the gap between the two ISO C++ standards grew so large.

The lesson for a learner is that a process can be slowed by a belief about rules, even when the rules say something different. Checking the premise before accepting a schedule constraint is a useful habit in any collaborative technical work.

The committee summarized the overall aims of the C++11 effort in two statements. These aims describe the effort as a whole, and they are worth remembering because they explain much of the direction the standard took.

The two objectives pull in somewhat different directions. A language built for power and efficiency can grow complicated, while a language that is easy to teach favors clarity. The committee presented both as goals of the same effort, which means C++11 was meant to serve both audiences at once rather than choosing one over the other.

The standard grew substantially between C++98 and C++11. The language grew by about 30 percent, and the standard library grew by about 100 percent. Growth of that size is easy to read as a sign of many new features, but most of it came from more detailed specification rather than new functionality. In other words, the same kinds of features were described far more precisely.

Why did the committee grow the document this way instead of adding features freely? The source points to a strong constraint: the committee had to take great care not to compromise older code through incompatible changes. It estimated that billions of lines of C++ code were in use, and it was not willing to break them. Expanding the specification without invalidating existing programs was therefore a central goal, and it is one reason the growth came through more detailed description rather than through changes that would break existing programs.