Chapter 2. The Origin Story
This may be old news to some readers, and is admittedly a C++-centric telling, but we want to provide a sketch of the history of C++ in order to put its recent resurgence in perspective.
The first programming languages, such as Fortran and Cobol, were developed to allow a domain specialist to write portable programs without needing to know the arcane details of specific machines.
But systems programmers were expected to master such details of computer hardware, so they wrote in assembly language. This gave programmers ultimate power and performance at the cost of portability and tedious detail. But these were accepted as the price one paid for doing systems programming.
The thinking was that you either were a domain specialist, and therefore wanted or needed to have low-level details abstracted from you, or you were a systems programmer and wanted and needed to be exposed to all those details. The systems-programming world was ripe for a language that allowed to you ignore those details except when access to them was important.
C: Portable Assembler
In the early 1970s, Dennis Ritchie introduced “C,”1 a programming language that did for systems programmers what earlier high-level languages had done for domain specialists. It turns out that systems programmers also want to be free of the mind-numbing detail and lack of portability inherent in assembly-language programming, but they still required a language that gave them complete control of the hardware when necessary.
C achieved this by shifting the burden of knowing the arcane details of specific machines to the compiler writer. It allowed the C programmer to ignore these low-level details, except when they mattered for the specific problem at hand, and in those cases gave the programmer the control needed to specify details like memory layouts and hardware details.
C was created at AT&T’s Bell Labs as the implementation language for Unix, but its success was not limited to Unix. As the portable assembler, C became the go-to language for systems programmers on all platforms.
C with High-Level Abstractions
As a Bell Labs employee, Bjarne Stroustrup was exposed to and appreciated the strengths of C, but also appreciated the power and convenience of higher-level languages like Simula, which had language support for object-oriented programming (OOP).
Stroustrup realized that there was nothing in the nature of C that prevented it from directly supporting higher-level abstractions such as OOP or type programming. He wanted a language that provided programmers with both elegance when expressing high-level ideas and efficiency of execution size and speed.
He worked on developing his own language, originally called C With Classes, which, as a superset of C, would have the control and power of portable assembler, but which also had extensions that supported the higher-level abstractions that he wanted from Simula. [DEC]
The extensions that he created for what would ultimately become known as C++ allowed users to define their own types. These types could behave (almost) like the built-in types provided by the language, but could also have the inheritance relationships that supported OOP.
He also introduced templates as a way of creating code that could work without dependence on specific types. This turned out to be very important to the language, but was ahead of its time.
The ’90s: The OOP Boom, and a Beast Is Born
Adding support for OOP turned out to be the right feature at the right time for the ʽ90s. At a time when GUI programming was all the rage, OOP was the right paradigm, and C++ was the right implementation.
Although C++ was not the only language supporting OOP, the timing of its creation and its leveraging of C made it the mainstream language for software engineering on PCs during a period when PCs were booming.
The industry interest in C++ became strong enough that it made sense to turn the definition of the language over from a single individual (Stroustrup) to an ISO (International Standards Organization) Committee.2 Stroustup continued to work on the design of the language and is an influential member of the ISO C++ Standards Committee to this day.3
In retrospect, it is easy to see that OOP, while very useful, was over-hyped. It was going to solve all our software engineering problems because it would increase modularity and reusability. In practice, reusability goes up within specific frameworks, but these frameworks introduce dependencies, which reduce reusability between frameworks.
Although C++ supported OOP, it wasn’t limited to any single paradigm. While most of the industry saw C++ as an OOP language and was building its popularity and installed base using object frameworks, others where exploiting other C++ features in a very different way.
Alex Stepanov was using C++ templates to create what would eventually become known as the Standard Template Library (STL). Stepanov was exploring a paradigm he called generic programming.
Generic programming is “an approach to programming that focuses on designing algorithms and data structures so that they work in the most general setting without loss of efficiency.” [FM2G]
Although the STL was a departure from every other library at the time, Andrew Koenig, then the chair of the Library Working Group for the ISO C++ Standards Committee, saw the value in it and invited Stepanov to make a submission to the committee. Stepanov was skeptical that the committee would accept such a large proposal when it was so close to releasing the first version of the standard. Koenig asserted that Stepanov was correct. The committee would not accept it…if Stepanov didn’t submit it.
Stepanov and his team created a formal specification for his library and submitted it to the committee. As expected, the committee felt that it was an overwhelming submission that came too late to be accepted.
Except that it was brilliant!
The committee recognized that generic programming was an important new direction and that the STL added much-needed functionality to C++. Members voted to accept the STL into the standard. In its haste, it did trim the submission of a number of features, such as hash tables, that it would end up standardizing later, but it accepted most of the library.
By accepting the library, the committee introduced generic programming to a significantly larger user base.
In 1998, the committee released the first ISO standard for C++. It standardized “classic” C++ with a number of nice improvements and included the STL, a library and programming paradigm clearly ahead of its time.
One challenge that the Library Working Group faced was that it was tasked not to create libraries, but to standardize common usage. The problem it faced was that most libraries were either like the STL (not in common use) or they were proprietary (and therefore not good candidates for standardization).
Also in 1998, Beman Dawes, who succeeded Koenig as Library Working Group chair, worked with Dave Abrahams and a few other members of the Library Working Group to set up the Boost Libraries.4 Boost is an open source, peer-reviewed collection of C++ libraries,5 which may or may not be candidates for inclusion in the standard.
Boost was created so that libraries that might be candidates for standardization would be vetted (hence the peer reviews) and popularized (hence the open source).
Although it was set up by members of the Standards Committee with the express purpose of developing candidates for standardization, Boost is an independent project of the nonprofit Software Freedom Conservancy.6
With the release of the standard and the creation of Boost.org, it seemed that C++ was ready to take off at the end of the ʽ90s. But it didn’t work out that way.
The 2000s: Java, the Web, and the Beast Nods Off
At over 700 pages, the C++ standard demonstrated something about C++ that some critics had said about it for a while: C++ is a complicated beast.
The upside to basing C++ on C was that it instantly had access to all libraries written in C and could leverage the knowledge and familiarity of thousands of C programmers.
But the downside was that C++ also inherited all of C’s baggage. A lot of C’s syntax and defaults would probably be done very differently if it were being designed from scratch today.
Making the more powerful user-defined types of C++ integrate with C so that a data structure defined in C would behave exactly the same way in both C and C++ added even more complexity to the language.
The addition of a streams-based input/output library made I/O much more OOP-like, but meant that the language now had two complete and completely different I/O libraries.
Adding operator overloading to C++ meant that user-defined types could be made to behave (almost) exactly like built-in types, but it also added complexity.
The addition of templates greatly expanded the power of the language, but at no small increase in complexity. The STL was an example of the power of templates, but was a complicated library based on generic programming, a programming paradigm that was not appreciated or understood by most programmers.
Was all this complexity worth it for a language that combined the control and performance of portable assembler with the power and convenience of high-level abstractions? For some, the answer was certainly yes, but the environment was changing enough that many were questioning this.
The first decade of the 21st century saw desktop PCs that were powerful enough that it didn’t seem worthwhile to deal with all this complexity when there were alternatives that offered OOP with less complexity.
One such alternative was Java.
As a bytecode interpreted, rather than compiled, language, Java couldn’t squeeze out all the performance that C++ could, but it did offer OOP, and the interpreted implementation was a powerful feature in some contexts.7
Because Java was compiled to bytecode that could be run on a Java virtual machine, it was possible for Java applets to be downloaded and run in a web page. This was a feature that C++ could only match using platform-specific plug-ins, which were not nearly as seamless.
So Java was less complex, offered OOP, was the language of the Web (which was clearly the future of computing), and the only downside was that it ran a little more slowly on desktop PCs that had cycles to spare. What’s not to like?
Java’s success led to an explosion of what are commonly called managed languages. These compile into bytecode for a virtual machine with a just-in-time compiler, just like Java. Two large virtual machines emerged from this explosion. The elder, Java Virtual Machine, supports Java, Scala, Jython, Jruby, Clojure, Groovy, and others. It has an implementation for just about every desktop and server platform in existence, and several implementations for some of them. The other, the Common Language Interface, a Microsoft virtual machine, with implementations for Windows, Linux, and OS X, also supports a plethora of languages, with C#, F#, IronPython, IronRuby, and even C++/CLI leading the pack.
Colleges soon discovered that managed languages were both easier to teach and easier to learn. Because they don’t expose the full power of pointers8 directly to programmers, it is less elegant, and sometimes impossible, to do some things that a systems programmer might want to do, but it also avoids a number of nasty programming errors that have been the bane of many systems programmers’ existence.
While things were going well for Java and other managed languages, they were not going so well for C++.
C++ is a complicated language to implement (much more than C, for example), so there are many fewer C++ compilers than there are C compilers. When the Standards Committee published the first C++ standard in 1998, everyone knew that it would take years for the compiler vendors to deliver a complete implementation.
The impact on the committee itself was predictable. Attendance at Standards Committee meetings fell off. There wasn’t much point in defining an even newer version of the standard when it would be a few years before people would begin to have experience using the current one.
About the time that compilers were catching up, the committee released the 2003 standard. This was essentially a “bug fix” release with no new features in either the core language or the standard library.
After this, the committee released the first and only C++ Technical Report, called TR1. A technical report is a way for the committee to tell the community that it considers the content as standard-candidate material.
The TR1 didn’t contain any change to the core language, but defined about a dozen new libraries. Almost all of these were libraries from Boost, so most programmers already had access to them.
After the release of the TR1, the committee devoted itself to releasing a new update. The new release was referred to as “0x” because it was obviously going to be released sometime in 200x.
Only it wasn’t. The committee wasn’t slacking off—they were adding a lot of new features. Some were small nice-to-haves, and some were groundbreaking. But the new standard didn’t ship until 2011. Long, long overdue.
The result was that although the committee had been working hard, it had released little of interest in the 13 years from 1998 to 2011.
We’ll use the history of one group of programmers, the ACCU, to illustrate the rise and fall of interest in C++. In 1987, The C Users Group (UK) was formed as an informal group for those who had an interest in the C language and systems programming. In 1993, the group merged with the European C++ User Group (ECUG) and continued as the Association of C and C++ Users.
By the 2000s, members were interested in languages other than C and C++, and to reflect that, the group changed its name to just the initials ACCU. Although the group is still involved in and supporting C++ standardization, its name no longer stands for C++, and members are also exploring other languages, especially C#, Java, Perl, and Python.9
By 2010, C++ was still in use by millions of engineers, but the excitement of the ʽ90s had faded. There had been over a decade with few enhancements released by the Standards Committee. Colleges and the cool kids were defecting to Java and managed languages. It looked like C++ might just turn into another legacy-only beast like Cobol.
But instead, the beast was just about to roar back.
1 http://cm.bell-labs.co/who/dmr/chist.html
2 http://www.open-std.org/jtc1/sc22/wg21/
3 Most language creators retain control of their creation or give them to standards bodies and walk away. Stroustrup’s continuing to work on C++ as part of the ISO is a unique situation.
4 http://www.boost.org/users/proposal.pdf
7 “Build once, run anywhere,” while still often not the case with Java, is sometimes much more useful for deployment than the “write once, build anywhere” type of portability of C++.
8 Java’s “references” can be null, and can be re-bound, so they are pointers; you just can’t increment them.