Reading C++ Language Revisions
The C++ Standards Committee maintains and refines the language definition so that implementers and users share one meaning for the language.
Why One Language Needs One Definition
Imagine two different companies that each build a compiler for the same programming language. Each compiler is written to a shared idea of what the language means, but each one quietly interprets a few details differently. A program written for the first compiler may then fail on the second. Over time, programmers stop trusting that the language means one thing at all. This slow loss of agreement is called fragmentation, and it is the problem a standards committee exists to prevent.
For C++, the body that performs this job is the C++ Standards Committee. Its purpose is to maintain and refine the language definition so that implementers, the people who build compilers, and users, the people who write programs, share one meaning for the language. The rest of this article follows how that committee came to exist and how it keeps the language coherent as it changes.
Predicting the Cost of Disagreement
What do you think happens?
If two compilers each read a few details of the language differently, what is the most likely result for a programmer?
Reveal answer
A program that works on one compiler may fail on the other
Differing interpretations break portability. Programs written for one compiler may fail on another, and programmers gradually lose confidence that the language has a single meaning. That loss of confidence is the danger of fragmentation.
Where the Reference Manual Came From
The committee did not start from nothing. AT&T Bell Labs made a decisive contribution by letting drafts of revised versions of the C++ reference manual circulate to implementers and to ordinary users. This mattered because many of those readers worked for companies that could be considered rivals of AT&T. A more guarded owner of the language could have kept the manual private, and the resulting silence would have invited fragmentation of its own.
Roughly a hundred individuals from dozens of organizations read those drafts and commented on them. Their feedback shaped the generally accepted reference manual, known as the ARM. The ARM then served as the base document for the ANSI standardization effort. The names of the reviewers are recorded in the published Annotated C++ Reference Manual.
Open review came before formal standardization. The shared, widely read draft is what gave the later committee work a common starting point.
From an American Committee to WG21
Standardization of C++ happened along two overlapping tracks. The first was the American national track. The X3J16 committee of ANSI was convened in December 1989, at the initiative of Hewlett-Packard. The second was the international track. In June 1991, the ANSI effort became part of an ISO standardization effort for C++, and the joint working group was named WG21.
The labels can look confusing at first, so keep them separate. X3J16 is the ANSI committee. WG21 is the ISO working group that the ANSI work was folded into. Read the milestones in order, because each stage depends on the one before it: shared reference manual drafts came first, then the ANSI committee, then the joint ISO working group, and then a public review draft in 1995 that sat between the early joint work and final ratification.
The Evolution Group and Proposed Changes
A living language needs a place where new ideas are weighed. From 1990 the joint committees were the main forum for C++ evolution. Within that work, a working group for extensions, later renamed the evolution group, handled proposals for major changes to C++ and for the addition of new language features. The group was chaired by a participant who sat on the joint committees throughout.
Reading the 1998 Standard Against the 2003 Release
The first ISO C++ standard, identified as ISO/IEC 14882-1998, was ratified by a 22-0 national vote in 1998. A bug-fix release of that standard followed in 2003. Because of this, you will sometimes encounter the name C++03. The 2003 release corrected errors rather than changing the language's design, so it describes essentially the same language as C++98.
Tracing a Milestone Through the Timeline
Placing the 2003 Release in the History
A colleague says the 2003 release is a new version of C++ that changed how the language works. Use the milestones to check this claim.
- 1Identify the ratified standard
The first ISO standard, ISO/IEC 14882-1998, was ratified by a 22-0 national vote in 1998.
- 2Identify what came next
A bug-fix release of that standard followed in 2003, sometimes called C++03.
- 3Check the purpose of a bug-fix release
The 2003 release corrected errors rather than changing the language's design.
- 4Compare the claim with the evidence
The 2003 release describes essentially the same language as C++98, so the colleague's claim that it changed how the language works is not supported.
The 2003 release should be understood as a corrected edition of one language, not a new language.
Mistakes Beginners Make with These Milestones
Common mistake Treating X3J16 and WG21 as two different languages
Why it failsThe labels name different bodies in one effort. X3J16 is the ANSI committee, and WG21 is the ISO working group that the ANSI work was folded into.
Do this insteadKeep the two labels separate as stages of one standardization path.
Common mistake Assuming C++03 is a new language because it has a newer year
What it looks likeReading the name C++03 and concluding the language was redesigned in 2003.
Why it failsThe 2003 release was a bug-fix release that corrected errors rather than changing the language's design.
Do this insteadRead C++03 as a corrected edition of the language standardized in 1998.
Common mistake Confusing the evolution group with the bug-fix work
Why it failsThe evolution group handled proposals for major changes and new language features. Error correction was a separate kind of work.
Do this insteadAssign major changes to the evolution group and error fixes to maintenance releases.
Common mistake Believing the committee exists only to write the first standard
Checking Your Reading of the Revisions
A friend says that because the 1998 standard and the 2003 release have different years, they define two different versions of C++ with different meanings. Explain whether this is correct, using the ratification, the bug-fix purpose, and the claim that the 2003 release describes essentially the same language.
Hints
- Look at what the 2003 release was intended to do.
- Check whether the 2003 release changed the design of the language or corrected errors.
- Consider the alias C++03 and what it tells you about the relationship to C++98.
Summary of Revision Reading
- 1The C++ Standards Committee maintains and refines the language definition so that implementers and users share one meaning for the language.
- 2The committee began with shared reference manual drafts, which fed the ARM and then the ANSI effort through X3J16.
- 3In June 1991 the ANSI work became part of an ISO effort, and the joint working group was named WG21.
- 4The evolution group handled proposals for major changes and new language features, while the 2003 bug-fix release corrected errors in ISO/IEC 14882-1998 without redesigning the language.
At a glance
- A standards committee exists to prevent fragmentation, so that compilers and programmers share one meaning for C++.
- The committee's work moved from the ANSI committee X3J16, convened in December 1989, to the ISO working group WG21, named in June 1991.
- The evolution group handled proposals for major changes and new language features within the joint committee work.
- ISO/IEC 14882-1998 and the 2003 bug-fix release, also called C++03, describe essentially the same language.