The C++ Source - A Pause to Reflect: Five Lists of Five, Part III - The Most Important C++ Software...Ever

http://www.artima.com/cppsource/top_cpp_software.html

The C++ Source
A Pause to Reflect: Five Lists of Five, Part III
The Most Important C++ Software...Ever
Opinion
by Scott Meyers
August 23, 2006

Advertisement

Summary

In this article, Scott Meyers shares his picks for the five most important software packages in the history of C++, along with why he chose them.

In my first two articles in this series, I named my picks for the most important contributions to C++ in the categories of books and non-book publications:

• “The Most Important C++ Books...Ever”
• “The Most Important C++ Non-Book Publications...Ever”

In this third installment, I will turn my attention to the most important C++ software...ever.

To write software in C++, you need tools to help you do it. In my view, those tools have been (and continue to be) the most important software related to C++. One can imagine one or more blockbuster applications developed in C++ that drove hordes of people to choose the language for future projects, but I’m not aware of that ever happening. The most important software for the language has been the bread-and-butter stuff of the software development crowd: compilers and libraries. Perhaps this is fitting for a language designed more for writing libraries than for writing applications.

My picks for the five most important pieces of software in the history of C++, ordered chronologically by first appearance, are:

• Cfront by AT&T Bell Telephone Laboratories, 1985-1993. In the beginning, there was Cfront, the original C++ compiler. It was a true compiler, but it generated C as its object code, so it was common to think of it as a preprocessor that translated C++ to C. It was hard not to think otherwise when debugging, because, at least when I started using it in 1988, there were no C++ debuggers. Instead, we grizzled pioneers used C debuggers and learned to mentally unmangle names (e.g., to recognize that __pl__1Aff in the debugger referred to some operator+ function in the C++ source code).

  The fact that Cfront generated C had two advantages. First, it was fairly easy to port Cfront to new platforms, because C compilers were ubiquitous. This facilitated the rapid spread of C++ to many environments. Second, it allowed users to look at the generated code to see what was going on during compilation. This helped demystify the language at a time when most people using it were C++ beginners trying to figure out how it worked. It also acted as a kind of security blanket. You didn’t really have to worry about C++ pulling the wool over your eyes if everything it did was sitting there in plain sight (or at least sight as plain as machine-generated C ever gets.)

  Until about 1990, Cfront not only compiled code, it also acted as the de facto language standard. C++ came from AT&T and Cfront came from the C++ group at AT&T, so whatever Cfront did had to be correct. For a time, this led to other compiler vendors adhering so closely to Cfront behavior, they reproduced its bugs, too. When the Annotated C++ Reference Manual (ARM) was published, Cfront’s role as a reference implementation gradually diminished, especially when it became clear that adding exception-handling support to Cfront called for Herculean effort.

  The final Cfront release was in 1993, but at least its ghost lives on. Edison Design Group—a company know for producing the most standard-conformant C++ front ends in the business—notes in a July 2006 document that they have a Cfront-compatibility mode. Personally, I suspect that there are a few Cfront implementations being used for embedded projects on platforms where there’s still no native C++ compiler, but that’s just speculation on my part.

• GCC by the GNU Project, 1987-present. GNU got into the C++ business early, and it released the first compiler generating native code (in contrast to Cfront’s C++-to-C translation). Over the years, the GNU compiler has become the preferred choice for cross-platform use. The fact that it’s a cross compiler has also made it popular for embedded systems development. GCC itself is a compiler platform supporting multiple front ends (e.g., C, C++, FORTRAN, etc.) and multiple back ends (for targeting different platforms); the version for C++ is known as g++.

  In the early days, the driving force behind g++ was Michael Tiemann. I fondly recall the time I submitted a g++ bug report, and, shortly thereafter, got a reply from Tiemann. He included a new production for the g++ grammar, along with a request that I add the production, rebuild the compiler, and see if the problem I’d reported went away. As I recall, the problem remained, but there’s just something about having the author of a compiler send you a mod and asking you to install it. Incidentally, Tiemann cofounded Cygnus Support in 1989, and I believe Cygnus was one of the first companies based on free software. (It’s reported that in the early days, Tiemann sometimes held meetings at Cygnus in a hot tub.)

  g++ is open source, so the C++ community has free access to a C++ front end that is, for all practical purposes, standard-conformant. Yet I don’t know of any open source tools (e.g., lints, refactoring tools, etc.) derived from the g++ code base that parse everything g++ does. There are tools that parse all C++ declarations (e.g., gccxml), but, as far as I know, none that parse both declarations and definitions (especially function bodies). This says something about g++’s front end, and though I have no personal experience with it, I doubt that it’s complimentary. This is unfortunate, because C++ developers could really use a larger tool set, but the barrier to entry for truly powerful tools is the ability to parse¹ C++ source code, and that’s a barrier very few have been able to breach.

• Visual C++ by Microsoft, 1992-present. Visual C++ (VC++) has been at once one of the most important reasons for the success of C++ and one of the most potent forces retarding its progress. Notwithstanding Bjarne Stroustrup’s assertion that “nobody knows what most C++ developers do,²” I have little doubt that if you lined up every C++ developer on the planet and polled them for the compiler or compilers they use for production work, a majority would mention VC++. For that reason alone, Visual C++ has been and continues to be important to C++. Furthermore, the flagship Microsoft products (e.g, operating systems and Microsoft Office applications) are written entirely or primarily in C++ and are compiled with the Visual C++ compiler. This, too, makes VC++ important in the world of C++. The company’s reliance on C++ has led them to develop tools and APIs to support its use, and that has motivated many Windows developers to adopt the language. By the late 1990s, C++ was known to many (and to my shock and dismay) as “the Microsoft language.”³ Visual C++ remains a dominating presence on the C++ landscape. For legions of programmers, Visual C++ is C++.

  Unfortunately, there were many years during which Microsoft’s implementation fell far short of the standard. Up until 1998, this wasn’t a problem, because there wasn’t any standard to adhere to, and compilers from other vendors had their own share of issues. However, Visual C++ 6 (VC6) was released in 1998, nearly a year after the C++ standard had been completed. VC6’s standards-conformance was less than exemplary, but at the time, that was not a serious problem, because relatively few programmers were using the “new” features of standard C++. What made it a serious problem was that VC6 remained the current Microsoft release until 2002 (when VC7 was released), and even then the compiler itself went largely unchanged. Rather, the primary improvement in standards conformance came in the form of an upgraded library (e.g., a more standards-conformant implementations of the STL), something many of us felt should have been done as a patch release years earlier. The 2003 release of Visual C++ (VC7.1) finally resolved most issues of standards conformance, but during the six years between VC6 and VC7.1, cross-platform developers using VC++ had to expend enormous effort to work around VC++’s failure to support things like partial template specialization, typically through conditional compilation (i.e., fragmented code bases). Furthermore, many developers continue to use VC6 even today, and those developers continue to be beholden to the decision the Visual C++ team made to largely ignore standards conformance for that release. (For such developers, for example, new doesn’t throw an exception if memory is exhausted, it returns the null pointer.)

  Since 2003, VC++ hasn’t had what I consider to be significant problems with standards conformance, and I’m convinced that the current leadership takes standards conformance seriously. Still, because I frequently work with developers whose lives (or at least whose code bases) were made unnecessarily difficult for the six-year span from 1998 through 2003, I’ve decided that I’m justified in harboring a grudge against Microsoft into 2008—six years from the time they released a “real” C++ compiler.

• The Standard Template Library, originally by HP, 1993-present. That the standard library for a language like C++ should offer a set of commonly-useful containers and algorithms is not particularly surprising, though if that were the extent of the STL’s contribution to C++, it’d probably still make the list. But the STL did far more than that. It also introduced an architecture for designing containers and algorithms so that each could work seamlessly with the other by communicating only through iterators. And it demonstrated how arrays and pointers could be considered containers and iterators, thus making the line between the language proper and its library blurrier than one might expect. And it showed how the architecture was extensible by users, allowing for the introduction of new containers, new algorithms, and new iterators types, each of which work as well with other STL-conformant components as the STL components themselves do. And it explained why there was little reason to distinguish between everything in a container and a subrange of a container. And it did all this with an eye towards efficiency, eschewing classic object-oriented inheritance-based solutions and relying almost exclusively on templates. It introduced generic programming to the C++ masses. The end result was a transformation in the way we thought about designing libraries and library frameworks, yet for people who were just looking for convenient, portable containers of T, it provided that, too. In Effective STL (Addison-Wesley, 2001), I wrote, “In the nearly 30 years I’ve been programming, I’ve never seen anything like the STL.” It’s now over 30 years, and I still haven’t.

• The Libraries at Boost, 1999-present. This selection is a bit of a cheat, because Boost isn’t a library, it’s an umbrella organization for a collection of libraries designed and implemented by a variety of people with a variety of design goals and sensibilities. As a result, the Boost libraries are somewhat scattershot in the functionality they provide as well as the way they go about providing it. Still, Boost and its libraries have been quite important to C++, and their influence seems likely to increase in the future. Of the 14 new kinds of functionality specified in TR1 (of which 13 are now in the draft for C++0x), ten⁴ are based on proposals derived from experience with Boost libraries. No other organization can claim anywhere near that kind of impact on the expanded library functionality to be provided in the next version of C++.

  Boost’s influence in this regard is hardly accidental. Boost was founded with the goal of acting as a testbed and advocate for libraries that might eventually be added to standard C++. That most of TR1 is based on work at Boost testifies to the success they’ve had, and it seems likely that TR2 will also contain plenty of Boost-based functionality.

  If you google for “C++ libraries” (without the quotes), you’ll find that Boost is the first hit. It’s debatable whether this suggests that when people think of C++ libraries, they should think of Boost, but it certainly demonstrates that Boost has become closely associated with C++ libraries.

Now, software tools have been critical to the success of C++, but in the end, pretty much everything boils down to people. That’s as true of C++ as of any other human endeavor. In my next installment in this series of articles, I’ll tell you who I think have been the most important people—the titans of the world of C++.⁵

Share Your Opinion

Discuss this article in the Articles Forum topic, The Most Important C++ Software...Ever.

End Notes

1. By “parse,” I mean more than simply building an abstract syntax tree. I also mean performing implicit template instantiation, resolving calls to overloaded functions, etc. This means I’m conflating parsing and semantic analysis, but the entry point for many powerful C++ tools is the results of semantic analysis, and in common parlance, people often refer to that entire process as “parsing.”

2. Because the community is too large and too diverse to allow meaningful claims about the behavior of “most programmers.”

3. “The Unix language” was Java. I have no idea what the Apple language was.

4. These 10 components are (in a mixture of my own and TR1’s terminology) reference wrappers, smart pointers, enhanced member pointer adapters (mem_fn), enhanced binders (bind), generalized Functors (function), type traits, random numbers, tuples, fixed-size arrays, and regular expressions.

5. Everyone agrees that titans are powerful, but my wife, a student of classics, can’t help but remind me that though the titans were strong, they had more in the way of brawn than brain. That’s why they came in second in their struggle with the gods of Olympus (Zeus and his crew.) I’ll leave it up to you to determine whether there’s a parallel with C++, and, if so, who or what plays the role of the Olympians.

Resources

Part I in this series, “The Most Important C++ Books...Ever”:
http://www.artima.com/cppsource/top_cpp_books.html

Part II, “The Most Important C++ Non-Book Publications...Ever”:
http://www.artima.com/cppsource/top_cpp_publications.html

Edison Design’s July 2006 document that mentions their Cfront-compatibility mode:
http://www.edg.com/cpp_ftrs.html

GCC by the GNU Project:
http://gcc.gnu.org/

Article reporting that Michael Tiemann sometimes held meetings at Cygnus in a hot tub:
http://www.findarticles.com/p/articles/mi_m3514/is_n6_v41/ai_16112996#continue

gccxml:
http://www.gccxml.org/

Visual C++ by Microsoft:
http://msdn.microsoft.com/visualc/

The Libraries at Boost:
http://boost.org/

Scott Meyers is the author of Effective C++, the third edition of which was published in 2005. It is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/0321334876/

Scott Meyers is also the author of More Effective C++, which is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/020163371X/

Scott Meyers is also the author of Effective STL, which is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/0201749629/

Scott Meyers’ home page:
http://www.aristeia.com/

About the Author

Scott Meyers is one of the world’s foremost authorities on C++; he provides training and consulting services to clients worldwide. He wrote the best-selling Effective C++ series (Effective C++, More Effective C++, and Effective STL), designed the innovative Effective C++ CD, is Consulting Editor for Addison Wesley’s Effective Software Development Series, and serves on the Advisory Board for The C++ Source (http://www.artima.com/cppsource/). He has a Ph.D in Computer Science from Brown University. His web site is aristeia.com.