Standardization and Compatibility in Programming Languages

Many programming languages are governed by a written standard, a document that defines what the language is and how it must behave. Readers often imagine that such standards appear at regular intervals, like a product release calendar. For widely used languages, that is not how it works. C++11 is the current version of C++, and it was developed over a long period by the members of the standards committee known as WG21. Understanding why that work took as long as it did reveals how standardization actually operates.

The delay in C++11 has three contributing causes: how the committee chose to operate, the growing size of modern languages, and a belief about ISO rules that turned out to be wrong. The sections below follow the timeline first, then the reasons behind the gap, then the design aims and the growth of the standard.

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 then produced for public review in 2009. Finally, the second ISO C++ standard, identified as ISO/IEC 14882-2011, was ratified by a 21-0 national vote in August 2011. Notice two details in the last step: the vote was a national vote, and the document became formally known as the second ISO C++ standard.

Read the timeline as a sequence of stages with long gaps between them. The bulk of the elapsed time sits in the years of feature work before the draft, which is where the committee's operating choices and the misreading of the ISO rules had their effect.

A proposed feature does not become part of the standard by being written down once. The source material describes the path from committee work to ratification in terms of a few anchor stages: committee feature work, a draft standard released for public review, and a final ratification by national vote. The flow below shows that sequence, using only the stages the source identifies.

Many people assume that a standards body must pause after publishing a standard, waiting a set period before designing the next round of features. Members of the C++ committee held this same impression about the ISO rules. The situation is more specific than a general pause, though. The committee believed a waiting period was required, and that belief was mistaken. 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 had misread. That delay is one reason the gap between the two ISO C++ standards grew so large. It is one contributing factor, not the whole explanation, since the other reasons come from how the committee operated and from the growing size of modern languages.

The committee summarized the overall aims of the C++11 effort in two statements. They are worth remembering because they explain much of the direction the standard took. The first aim is to make the language better for systems programming and library building. The second is to make the language easier to teach and learn.

The two aims pull in somewhat different directions. The first serves people who build systems and libraries, who need a powerful and efficient language. The second serves people who learn and teach the language, who benefit from clarity and simplicity. The effort was meant to serve both audiences at once, so a feature that helps experts but confuses learners works against one of the stated aims.

A useful way to hold the two aims together is to ask, for any proposed change, who it helps. A change that strengthens systems programming serves the first audience. A change that makes the language clearer to learners serves the second. C++11 was expected to satisfy both kinds of benefit.

The standard grew substantially between editions. The language itself grew by about 30 percent, and the standard library grew by about 100 percent. Most of that growth came from more detailed specification rather than from new functionality. In other words, much of the expansion was the committee writing down behavior more precisely, not adding new features alone.

Why did the committee grow the standard mostly through detailed specification? Any new standard has to balance improvement against stability. The committee had to take great care not to compromise older code through incompatible changes. The source estimates that billions of lines of C++ code were in use, and the committee was not willing to break them. This constraint shaped the work as much as the design goals did. It is one reason the standard grew through more precise definitions rather than through changes that would invalidate existing programs.