Evolution of C++ Standards

Suppose two different companies each build a compiler for the same language. Each one quietly interprets a few details differently. A program written for one compiler may then fail on the other, and programmers slowly lose confidence that the language means one thing. This is the danger of fragmentation, and it is the problem a standards committee exists to prevent.

For C++, the body that performs this job is known as the C++ Standards Committee. Its purpose is to maintain and refine the language definition so that implementers and users share one meaning for the language. Understanding how that committee worked, and how its structure changed, explains much of how C++ reached its modern form. This article follows that history as a sequence of states: what the standardization effort looked like at each stage, what changed, and what stayed the same.

A standard is a shared definition. Without one, every compiler author is free to decide what an ambiguous or unspecified detail means, and every user inherits those decisions. The committee's work is therefore not only about adding features. It is also about keeping the definition precise enough that two independent implementations agree on the meaning of the same program.

The committee did not begin 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 less cooperative 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 what became the generally accepted reference manual, known as the ARM, which in turn served as the base document for the ANSI standardization effort. The names of those reviewers are recorded in the published Annotated C++ Reference Manual.

Standardization then ran on 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, so keep them separate: X3J16 is the ANSI committee, and WG21 is the ISO working group that the ANSI work was folded into. From 1990 the joint committees were the main forum for C++ evolution.

Read the timeline as a series of states. At the start, the language is defined by a manual that is shared but not yet a standard. The ANSI track gives it a national standardization home. The ISO track gives it an international home under WG21. Each state depends on the one before it: the ANSI work built on the ARM, and the ISO work built on the ANSI effort.

A living language needs a place where new ideas are weighed. The source describes a working group for extensions, later renamed the evolution group, that was chaired by a participant who sat on the joint committees throughout. This group was directly responsible for handling proposals for major changes to C++ and for the addition of new language features.

The division of labor matters. The joint committees were the main forum for C++ evolution, and the evolution group was the part of that forum that examined major changes and new features. Its existence means that a proposal for something new does not have to be decided ad hoc by any single compiler vendor. It enters a shared process where the whole committee can weigh it.

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 source is explicit that this is essentially the same language as C++98.

The source does not list each individual correction made in 2003, so the honest summary is the one the source gives: the design stayed the same and the errors were fixed. A useful habit is to treat C++98 and C++03 as two editions of one definition, not as two languages competing with each other.

Classic C has two main descendants, ISO C and ISO C++. The source describes them as siblings rather than parent and child. Both came from the same starting point, Classic C, and both are standards in their own right. Neither is a subset that simply extends the other.

The source also mentions BCPL, defined by Richards in 1980, and C89, which the source cites as C90. These references mark the broader history behind the standards. The source does not walk through each revision in detail, so this lineage is best held at the level of Classic C followed by its two ISO branches.

Imagine a team that maintains a large body of older C code and also writes new code in C++. A natural assumption is that C++ simply accepts everything C accepts, so the old code and the new code should mix freely. The source corrects this assumption. Neither ISO C nor ISO C++ is 100% compatible with Classic C, and the two standards evolved at different paces and in different directions.

The mechanism of divergence is simple to state. Two standards start from one baseline. Each then receives its own revisions, its own proposals, and its own committee decisions. Over successive revisions, the two definitions move apart. The source confirms the fact of the drift and the difference in pace and direction, but it does not provide a revision-by-revision account of where the gap grew largest.

The source names three groups affected by the incompatibilities between ISO C and ISO C++. The first group is people who use both C and C++. The second group is people who write in one language while using libraries implemented in the other. The third group is implementers of libraries and tools for C and C++. The source says these incompatibilities can make life miserable for all three groups.

Each group reaches the problem differently. An application developer who uses both languages meets it directly in their own code. A developer who writes in one language but relies on a library from the other meets it at the boundary, where the library's assumptions differ from their own. A library or tool implementer meets it in the design of the code they must support for both languages. The source identifies all three groups, so the incompatibility is a practical concern for the whole ecosystem, not only for compiler authors.