The History of C++ Standards
C++11, known for years as C++0x, was produced by the WG21 committee and ratified by a 21-0 national vote in August 2011 as the second ISO C++ standard.
Why Language Standards Do Not Arrive on a Schedule
What do you think happens?
Before reading on: how was the second ISO C++ standard approved?
Reveal answer
By a national vote of 21 to 0 in August 2011.
The second ISO C++ standard, identified as ISO/IEC 14882-2011, was ratified by a 21-0 national vote in August 2011. Keep this vote in mind, because the rest of the article traces how the work reached that point.
C++11 is the version of C++ this article follows. It was developed over a long period by the members of the standards committee known as WG21. Standards for widely used languages do not appear on a fixed schedule, so the length of this work is not unusual in itself. Understanding it requires looking at three things: how the committee chose to operate, the growing size of modern languages, and a belief that turned out to be wrong.
The Working Name C++0x
For years this version of the language was known as C++0x. That was a working name that reflected the hope that the standard would finish within the current decade. The name changed when the work was completed, but the standard it refers to is the same document. When you see C++0x in older discussions, it means the same effort that later became C++11.
The Waiting-Period Misconception
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, though, the situation is more specific. 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 of the reasons the gap between the two ISO C++ standards grew so large. The source names other reasons as well, so the misreading should be treated as one contributing factor rather than the whole explanation.
Three Anchor Points on the Path to C++11
The source gives three anchor points that together describe the path to C++11. 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 was then ratified by a 21-0 national vote in August 2011. Note that the approval was a national vote, and that the document was formally the second ISO C++ standard.
The timeline shows that most of the elapsed time sat before the public draft. Once the draft existed, the path to ratification took about two more years. The long interval from the start of feature work to the 2009 draft is where the committee's misreading of the waiting-period rule had its effect.
Working Through the Length of the Gap
How long did feature work take to reach ratification?
Using only the anchor dates from the source, estimate how many years passed between the start of serious feature work in 2002 and the ratification vote in August 2011.
- 1Identify the start date
Serious feature work on the language began in 2002.
- 2Identify the end date
The second ISO C++ standard was ratified in August 2011.
- 3Subtract the years
2011 minus 2002 gives 9 years. Because the vote was in August, the span is roughly nine years.
- 4Check against the intermediate milestone
The 2009 public draft lies between the two dates. From 2002 to 2009 is about 7 years, and from 2009 to 2011 is about 2 years. Those parts add up to the same 9 years.
About nine years separated the start of serious feature work from ratification, with roughly seven of those years passing before the initial draft was published for public review.
Two Stated Design Objectives
The committee summarized the overall aims of the C++11 effort in two statements. The source presents them as the aims for the effort as a whole and notes that they are documented and explained in more detail elsewhere. They are worth remembering because they explain much of the direction the standard took.
| Audience | Stated aim | What that audience needs |
|---|---|---|
| People who build systems and libraries | Make the language better for systems programming and library building | A powerful and efficient language |
| People who learn and teach the language | Make the language easier to teach and learn | Clarity and simplicity |
The two stated objectives of C++11, mapped to the audiences the source names
The two objectives pull in somewhat different directions. The first serves experts who need a powerful and efficient language. The second serves learners and teachers who benefit from clarity and simplicity. The source presents both as goals of the same effort, so C++11 was meant to serve both audiences at once.
How the Standard Grew
The standard grew substantially. The source gives the growth as about 30 percent in the language and about 100 percent in the standard library. The standard library roughly doubled, while the language itself grew by roughly a third. The diagram below contrasts the before and after states for each part.
Why Growth Came From Detailed Specification
A reader might expect such growth to come mostly from new features. The source says otherwise: most of the growth came from more detailed specification rather than new functionality. In other words, much of the added length described existing behavior more precisely, so that implementations and programmers could rely on it.
This choice connects to a constraint the committee took seriously. Any new standard has to balance improvement against stability. The source notes that the committee had to take great care not to compromise older code through incompatible changes. Its estimate is that billions of lines of C++ code were in use, and the committee was not willing to break them. Changes that would invalidate existing programs were therefore avoided, and the growth was channeled into clearer specification.
Mistakes Learners Make About This History
Common mistake Assuming the standards committee had to wait a fixed period before starting new feature work
Why it failsThe source says the committee believed a waiting period was required, but that belief was a misreading of the ISO rules.
Do this insteadTreat the delay as a consequence of the committee's own choice, and as one contributing factor among several.
Common mistake Treating C++0x and C++11 as two different documents
Why it failsC++0x was a working name for the same standard that was later finished as C++11.
Do this insteadRead C++0x as the earlier name for the effort that produced C++11.
Common mistake Assuming the standard doubled in every area
Why it failsThe language grew by about 30 percent, while the standard library grew by about 100 percent.
Do this insteadKeep the two growth figures separate when describing how the standard changed.
Common mistake Believing the growth came mainly from new features, when the source says it came mainly from more detailed specification
Checking Your Understanding of the Timeline
Without looking back, list the three anchor points on the path to C++11 in order, and state which one was a national vote. Then explain in one or two sentences why the committee's belief about a waiting period mattered to the length of the gap.
Hints
- Start with the year serious feature work began, then the year of the public draft, then the ratification.
- The ratification was the national vote of 21 to 0 in August 2011.
- Think about what the committee chose to do during the period it believed it had to wait.
Key Takeaways
- C++11, known for years as C++0x, was produced by the WG21 committee and ratified as the second ISO C++ standard by a 21-0 national vote in August 2011.
- Serious feature work began in 2002, after the committee chose to delay it on the strength of a waiting-period belief that was mistaken; this was one contributing factor to the long gap.
- The two stated aims were to make the language better for systems programming and library building, and to make it easier to teach and learn.
- The standard grew by about 30 percent in the language and about 100 percent in the standard library, mostly through more detailed specification rather than new functionality, in part to protect billions of lines of existing code.