Lesson 19: History and Compatibility

Lesson 0019 — A Tour of C++, Chapter 19 (§19.1–§19.5)

C++ was designed to provide Simula's facilities for program organization together with C's efficiency and flexibility for systems programming. Simula was the initial source of C++'s abstraction mechanisms — the notion of class (with derived classes and virtual functions) was borrowed from it; templates and exceptions came later, with different sources of inspiration. This final technical chapter looks backward: the history of the language (timeline, early years, the standards process, style, use, and the model), the evolution of features and library components across C++11/14/17/20, what has been removed or deprecated, and the relationship with C. The thread running through it: the standard defines what works; the Core Guidelines define what is good use — and they are different things.

19.1 History

Bjarne Stroustrup invented C++, wrote its early definitions, and produced its first implementation; he chose and formulated the design criteria, designed its major language features, developed or helped to develop many of the early libraries, and for 25 years was responsible for the processing of extension proposals in the standards committee. The evolution of C++ was always in the context of its use: he spent a lot of time listening to users, seeking out the opinions of experienced programmers, and writing code. His colleagues at AT&T Bell Laboratories were essential for the growth of C++ during its first decade.

19.1.1 Timeline

The work that led to C++ started in the fall of 1979 under the name "C with Classes." Here is a simplified timeline:

During development, C++11 was known as C++0x — as is not uncommon in large projects, they were overly optimistic about the completion date; towards the end they joked that the 'x' in C++0x was hexadecimal, so that C++0x became C++0B. On the other hand, the committee shipped C++14, C++17, and C++20 on time, as did the major compiler providers.

19.1.2 The Early Years

Stroustrup originally designed and implemented the language because he wanted to distribute the services of a UNIX kernel across multiprocessors and local-area networks (what are now known as multicores and clusters). For that, he needed to precisely specify parts of a system and how they communicated: Simula would have been ideal, except for performance considerations; C would have been ideal for dealing directly with hardware and providing high-performance concurrent programming, except for its weak support for modularity and type checking. The result of adding Simula-style classes to C — "C with Classes" — was used for major projects in which its facilities for writing programs that use minimal resources were essential.

The name C++ (pronounced "see plus plus") was coined by Rick Mascitti in the summer of 1983; "++" is the C increment operator, signifying the evolutionary nature of the changes from C. The slightly shorter name "C+" is a syntax error. C++ was designed primarily so that Stroustrup and his friends would not have to program in assembler, C, or various then-fashionable high-level languages; its main purpose was to make writing good programs easier and more pleasant for the individual programmer. In the early years there was no C++ paper design — design, documentation, and implementation went on simultaneously — and no "C++ design committee": throughout, C++ evolved to cope with problems encountered by users.

The very first design included function declarations with argument type checking and implicit conversions, classes with the public/private distinction between interface and implementation, derived classes, and constructors and destructors. In retrospect, Stroustrup considers the introduction of constructors and destructors the most significant step — here is the root of C++'s strategies for resource management (causing a demand for exceptions) and the key to many techniques for making user code short and clear. Destructors were new in C++; no other language at the time supported multiple constructors capable of executing general code. By the October 1985 commercial release, C++ had gained inlining, consts, function overloading, references, operator overloading, and virtual functions — of these, support for run-time polymorphism in the form of virtual functions was by far the most controversial (systems programmers tended to view indirect function calls with suspicion, and doubted virtual functions could be fast enough for systems code). Early documents described C++ as "a general-purpose programming language that is a better C, supports data abstraction, and supports object-oriented programming" — notably, not "an object-oriented programming language." In the second half of the 1980s the most important additions were templates and exception handling, both considered experimental when the standards effort started; in designing templates, Stroustrup was forced to choose between flexibility, efficiency, and early type checking — he chose the first two, a choice he still considers correct. He also generalized inheritance to support multiple base classes (multiple inheritance of abstract classes — "interfaces" — is now universal in statically typed OO languages). The most important innovation in the 1998 standard library was the STL — a framework of algorithms and containers, the work of Alex Stepanov (with Dave Musser, Meng Lee, and others), based on more than a decade's work on generic programming. It was Stroustrup's deliberate policy to have the evolution of C++ "problem driven" rather than imitative: the determining influences always came from the applications he encountered.

19.1.3 The ISO C++ Standards

During 1987 it became clear that formal standardization of C++ was inevitable. AT&T Bell Labs made a major contribution by allowing Stroustrup to share drafts of revised versions of the C++ reference manual with implementers and users — about a hundred individuals from dozens of organizations read and commented on what became the base document for the ANSI C++ standardization effort (their names are in the ARM). The C++11 standard is the work of the members of WG21 (ISO SC22/WG21, now about 350 members). C++11, known for years as C++0x, was ratified by a 21-0 national vote in August 2011. One reason for the long gap between standards: most committee members were under the mistaken impression that ISO rules required a "waiting period" after a standard before starting new work — serious work on new features did not start until 2002. Other reasons: the language grew by about 30% in pages of standards text and the standard library by about 100%, and the work had to take great care not to compromise older code through incompatible changes. The overall aims for the C++11 effort were to make C++ a better language for systems programming and library building, and to make C++ easier to teach and learn. A major effort made concurrent systems programming type-safe and portable: a memory model (§18.1) and support for lock-free programming (Hans Boehm, Brian McKnight, and others), and on top of that the threads library.

After C++11 there was wide agreement that 13 years between standards were far too many. Herb Sutter proposed the "train model": shipping on time at fixed intervals. Stroustrup argued strongly for a short interval to minimize the chance of delays from someone insisting on "just one more essential feature." They agreed on an ambitious 3-year schedule, alternating between minor and major releases:

• C++14 was deliberately a minor release aiming at "completing C++11" — with a fixed release date, features that are known and wanted but not deliverable on time must wait, and gaps in the feature set will inevitably be discovered in widespread use.
• C++17 was meant to be a major release, but was at best a medium one: the features that would have made dramatic changes (concepts, modules, coroutines) were either not ready or became mired in controversy. It includes a little bit for everyone, but nothing that would significantly change the life of a programmer who had absorbed C++11 and C++14.
• C++20 offers long-promised and much-needed major features — modules, concepts, coroutines, ranges — and is as major an upgrade as C++11. It was approved by a unanimous 79-0 vote in Prague (later ratified by a national body vote of 22-0) and became widely available in late 2021.

Dangers for such a large and diverse committee include "design by committee," feature bloat, lack of consistent style, and short-sighted decisions — avoiding complexity creeping in from "minor useful features" and fashion is very hard.

19.1.4 Standards and Style

A standard says what will work, and how. It does not say what constitutes good and effective use. There are significant differences between understanding the technical details of language features and using them effectively in combination with other features, libraries, and tools to produce better software — by "better" Stroustrup means "more maintainable, less error-prone, and faster." We need to develop, popularize, and support coherent programming styles, and to support the evolution of older code to these more modern styles. It is extremely difficult to make large groups of programmers depart from something that works for something better — there are still people who see C++ as a few minor additions to C, and people who enthusiastically overuse novel facilities (e.g., programmers convinced that only code using massive amounts of template metaprogramming is true C++). What is Modern C++? In 2015, Stroustrup set out to answer this question by developing a set of coding guidelines supported by articulated rationales; together with people from Microsoft, Red Hat, and Facebook, he started the C++ Core Guidelines project — an ambitious project aiming at complete type-safety and complete resource-safety as a base for simpler, faster, safer, and more maintainable code, backed up with static analysis tools and a tiny support library.

19.1.5 C++ Use

C++ is now a very widely used programming language. Its user population grew from one in 1979 to about 400,000 in 1991 — the number of users doubled about every 7.5 months for more than a decade. The growth rate slowed after that, but there were about 4.5 million C++ programmers in 2018 and maybe a million more in 2022. Much of that growth happened after 2005, when the exponential explosion of processor speed stopped so that language performance grew in importance. This growth was achieved without formal marketing or an organized user community. C++ is primarily an industrial language — more prominent in industry than in education or programming language research — used where problems require C++'s combination of the ability to use hardware effectively and to manage complexity: microelectronics, Web applications and infrastructure, operating systems, financial, medical, automobile, aerospace, high-energy physics, biology, energy production, machine learning, video games, graphics, animation, virtual reality, and much more.

19.1.6 The C++ Model

The C++ language can be summarized as a set of mutually supportive facilities:

• A static type system with equal support for built-in types and user-defined types;
• Value and reference semantics;
• Systematic and general resource management (RAII);
• Support for efficient object-oriented programming;
• Support for flexible and efficient generic programming;
• Support for compile-time programming;
• Direct use of machine and operating system resources;
• Concurrency support through libraries (often implemented using intrinsics).

The standard-library components add further essential support for these high-level aims.

19.2 C++ Feature Evolution

The language features and standard-library components added for C++11, C++14, C++17, and C++20. A language feature is not meant to be used in isolation — most features that are new in C++11 make no sense in isolation from the framework provided by older features (advice 3: don't focus on language features in isolation when learning C++).

19.2.1–19.2.4 Language Features

19.2.5–19.2.8 Standard-Library Components

The additions come in two forms: new components (such as the regular expression matching library) and improvements to C++98 components (such as move constructors for containers).

19.2.9 Removed and Deprecated Features

There are billions of lines of C++ "out there," and nobody knows exactly what features are in critical use; the ISO committee removes older features only reluctantly and after years of warning. By deprecating a feature, the committee expresses the wish that the feature will go away — a deprecation is a strong hint to avoid the feature, but it may disappear only in the future. Compilers are likely to issue warnings for uses of deprecated features; however, deprecated features tend to remain supported "forever" for reasons of compatibility, and even removed features tend to live on in implementations because of user pressure.

• Removed: exception specifications (void f() throw(X,Y); — now an error) and their support facilities (unexpected_handler, set_unexpected(), get_unexpected(), unexpected()) — use noexcept instead.
• Removed: trigraphs.
• Removed: auto_ptr — use unique_ptr instead.
• Removed: the storage specifier register; the use of ++ on a bool.
• Removed: the C++98 export feature — it was complex and not shipped by the major vendors; export is now a keyword for modules.
• Removed: assignment of a string literal to a char* — use const char* or auto; some standard-library function objects related to argument binding — use lambdas and function.
• Deprecated: generation of copy operations for a class with a destructor; comparisons of enum values with values from a different enum or a floating-point value; comparisons between two arrays; comma operations in a subscript (e.g., [a,b]) — to make room for user-defined operator[]() with multiple arguments; implicit capture of *this in lambda expressions — use [=,this]; the standard-library interface for garbage collectors; strstream — use spanstream.

19.3 C/C++ Compatibility

With minor exceptions, C++ is a superset of C (meaning C11). Most differences stem from C++'s greater emphasis on type checking. Well-written C programs tend to be C++ programs as well — for example, every example in K&R2 is C++. A compiler can diagnose every difference between C++ and C; the C11/C++20 incompatibilities are listed in Appendix C of the standard.

19.3.1 C and C++ Are Siblings

Classic C (K&R C plus enumerations and struct assignment) has two main descendants: ISO C and ISO C++. Over the years these languages have evolved at different paces and in different directions — each provides support for traditional C-style programming in slightly different ways, and the resulting incompatibilities can make life miserable for people who use both languages, for people who write in one language using libraries implemented in the other, and for implementers of libraries and tools for both. ISO C and ISO C++ emerge as the two major descendants of K&R C, and as siblings: each carries the key aspects of Classic C, and neither is 100% compatible with it. (There was a C++03, not listed because it was a bug-fix release; similarly C17 is a bug-fix release to C11.) Note that differences between C and C++ are not necessarily the result of changes made in C++ — in several cases the incompatibilities arise from features adopted incompatibly into C long after they were common in C++ (e.g., the ability to assign a T* to a void*, and the linkage of global consts).

19.3.2 Compatibility Problems

There are many minor incompatibilities between C and C++; all can cause problems, but in the context of C++ all can be coped with — if nothing else, C code fragments can be compiled as C and linked to using the extern "C" mechanism. The major problems for converting a C program to C++ are likely to be:

• Suboptimal design and programming style.
• A void* implicitly converted to a T* (that is, converted without a cast).
• C++ keywords, such as class and private, used as identifiers in C code.
• Incompatible linkage of code fragments compiled as C and fragments compiled as C++.

19.3.2.1 Style Problems

Naturally, a C program is written in a C style: widespread use of pointers and arrays, and probably many macros. These facilities are hard to use reliably in a large program; resource management and error handling are often ad hoc, incompletely documented and adhered to. A simple line-for-line conversion of a C program into a C++ program yields a program that is often a bit better checked — Stroustrup has never converted a C program into C++ without finding some bugs — but the fundamental structure is unchanged, and so are the fundamental sources of errors. The advice for conversion:

• Don't think of C++ as C with a few features added. C++ can be used that way, but only suboptimally — to get really major advantages you need to apply different design and implementation styles.
• Use the C++ standard library as a teacher of new techniques and programming styles (note the difference from the C standard library — e.g., = rather than strcpy() for copying).
• Macro substitution is almost never necessary in C++: use const/constexpr/enum class for manifest constants, inline to avoid function-calling overhead, templates for families of functions and types, and namespaces to avoid name clashes.
• Don't declare a variable before you need it, and initialize it immediately.
• Don't use malloc() — new does the same job better; instead of realloc(), try a vector. Don't just replace malloc()/free() with "naked" new/delete.
• Avoid void*, unions, and casts, except deep within the implementation of some function or class — their use limits the support you can get from the type system and can harm performance. In most cases, a cast is an indication of a design error.
• If you must use an explicit type conversion, use an appropriate named cast (e.g., static_cast) for a more precise statement of what you are trying to do.
• Minimize the use of arrays and C-style strings — standard-library strings, arrays, and vectors can often be used to write simpler and more maintainable code. In general, try not to build yourself what has already been provided by the standard library.
• Avoid pointer arithmetic except in very specialized code (such as a memory manager).
• Pass contiguous sequences (e.g., arrays) as spans — a good way to avoid range errors ("buffer overruns") without added tests.
• For simple array traversal, use range-for — easier to write, as fast as, and safer than a traditional C loop.
• Use nullptr rather than 0 or NULL.
• Do not assume that something laboriously written in C style (avoiding classes, templates, and exceptions) is more efficient than a shorter alternative using standard-library facilities — often, but of course not always, the opposite is true.

19.3.2.2 void*

In C, a void* may be used as the right-hand operand of an assignment to or initialization of a variable of any pointer type; in C++ it may not:

void f(int n) {
    int* p = malloc(n*sizeof(int));   // not C++; in C++, allocate using "new"
    // ...
}

This is probably the single most difficult incompatibility to deal with. Note that the implicit conversion of a void* to a different pointer type is not in general harmless:

char ch;
void* pv = &ch;
int* pi = pv;    // not C++
*pi = 666;       // overwrite ch and other bytes near ch

In both languages, cast the result of malloc() to the right type. If you use only C++, avoid malloc().

19.3.2.3 Linkage

C and C++ can be (and often are) implemented to use different linkage conventions. The most basic reason is C++'s greater emphasis on type checking; a practical reason is that C++ supports overloading, so there can be two global functions called open() — this has to be reflected in the way the linker works. To give a C++ function C linkage (so it can be called from a C program fragment) or to allow a C function to be called from a C++ program fragment, declare it extern "C":

extern "C" double sqrt(double);

Now sqrt(double) can be called from a C or a C++ code fragment. Only one function of a given name in a scope can have C linkage (because C doesn't allow function overloading). A linkage specification does not affect type checking — the C++ rules for function calls and argument checking still apply to a function declared extern "C".

19.4 Bibliography

The chapter closes with a full bibliography of the sources referenced throughout the book — the ISO standards documents ([C++,1998] through [C++,2020]), the C standards, Stroustrup's HOPL history papers ([Stroustrup,1993], [Stroustrup,2007], [Stroustrup,2020]), The Design and Evolution of C++ ("D&E") [Stroustrup,1994], the K&R C book [Kernighan,1978], the C++ Core Guidelines [Stroustrup,2015], and the WG21 document archive. Most of the documents produced as part of the ISO C++ standards effort are available online [WG21].

19.5 Advice

Here is a summary of the guidance from this chapter. All 19 items, with the section where each is introduced. The C++ Core Guidelines link each item to its recommended practice.

Retrieval Quiz

Notes

Primary source: Stroustrup, B. (2022). A Tour of C++, 3rd ed., Chapter 19: "History and Compatibility." Addison-Wesley.
Reference: Chapter 1–12 Quick Reference & Glossary — keep it beside you while you study.
Recommended supplement: the C++ Core Guidelines, Stroustrup's HOPL papers, and the WG21 document archive.

Questions? Ask your agent — your teacher — about anything unclear: why the "waiting period" myth delayed C++11, what happened to export, or when extern "C" is actually needed. Follow-ups are expected, not optional.

Chapters

1. Lesson 1: The Basics (Ch. 1)
2. Lesson 2: User-Defined Types (Ch. 2)
3. Lesson 3: Separate Compilation (Ch. 3)
4. Lesson 4: Error Handling (Ch. 4)
5. Lesson 5: Classes (Ch. 5)
6. Lesson 6: Essential Operations (Ch. 6)
7. Lesson 7: Templates (Ch. 7)
8. Lesson 8: Concepts and Generic Programming (Ch. 8)
9. Lesson 9: Library Overview (Ch. 9)
10. Lesson 10: Strings and Regular Expressions (Ch. 10)
11. Lesson 11: Input and Output (Ch. 11)
12. Lesson 12: Containers (Ch. 12)
13. Lesson 13: Algorithms (Ch. 13)
14. Lesson 14: Ranges (Ch. 14)
15. Lesson 15: Pointers and Containers (Ch. 15)
16. Lesson 16: Utilities (Ch. 16)
17. Lesson 17: Numerics (Ch. 17)
18. Lesson 18: Concurrency (Ch. 18)
19. Lesson 19: History and Compatibility (Ch. 19 — this lesson)