7. Interest and Use

Some languages are designed to solve a problem; others are designed to prove a point.

— Dennis M. Ritchie

C++ usage — compilers — conferences, books, and journals — tools and environments — ways of learning C++ — users and applications — commercial competition — alternatives to C++ — expectations and attitudes.

Date	Estimated number of C++ users
Oct 1979	1
Oct 1980	16
Oct 1981	38
Oct 1982	85
Oct 1983	??+2 (no Cpre count)
Oct 1984	??+50 (no Cpre count)
Oct 1985	500
Oct 1986	2,000
Oct 1987	4,000
Oct 1988	15,000
Oct 1989	50,000
Oct 1990	150,000
Oct 1991	400,000

In other words, the C++ user population on average doubled every seven and a half months during these twelve years. These are conservative figures. C++ users have never been easy to count. First, there are implementations such as GNU’s G++ and Cfront shipped to universities for which no meaningful records can be kept. Second, many companies – both tools suppliers and end-users – consider the number of their users and the kind of work they do secret. However, I always had many friends, colleagues, contacts, and compiler suppliers who were willing to trust me with figures as long as I used them in a responsible manner. This enabled me to estimate the number of C++ users. These estimates were created by taking the number of users reported to me or estimated based on personal experience, rounding them all down, adding them, and then rounding down again. These numbers are the estimates made at the time and are not adjusted in any way. To support the claim that these figures are conservative, I can mention that Borland, the largest single C++ compiler supplier, publicly stated that it had shipped 500,000 compilers by October 1991. That figure is plausible and also credible because Borland is a public company.

The number of C++ users has now reached the point where I have no reasonable way of counting them. I don’t think I could determine the current number of C++ users to the nearest 100,000. Public figures show that well over 1,000,000 C++ compilers had been sold by late 1992.

Later, more conventional forms of communication and marketing arose. After AT&T released Cfront 1.0, some resellers, notably John Carolan’s Glockenspiel in Ireland and their US distributor Oasys (later part of Green Hills), started some minimal advertising in 1986. When independently developed C++ compilers such as Oregon Software’s C++ Compiler and Zortech’s C++ Compiler appeared, C++ became a common sight in ads (from about 1988).

The Santa Fe conference set a good example for future conferences with a mix of papers on applications, programming and teaching techniques, ideas for improvements to the language, libraries, and implementation techniques. Notably for a USENIX conference, there were papers on C++ on the Apple Macintosh, OS/2, the Connection machine, and for implementing non-UNIX operating systems (for example, CLAM [Call, 1987] and Choices [Campbell, 1987]). The NIH library [Gorlen, 1987] and the Interviews library [Linton, 1987] also made their public debuts in Santa Fe. An early version of what became Cfront 2.0 was demonstrated and I gave the first public presentation of its features [Stroustrup, 1987c]. The USENIX C++ conferences continue to be the primary technically and academically oriented C++ conference. The proceedings from these conferences are among the best readings about C++ and its use.

The Santa Fe conference was meant to be a workshop and because of the intensity of the discussions, it actually was a workshop despite the 200 participants. It was obvious, however, that at the next conference the experts would be drowned by the novices and by people trying to figure out what C++ was. That would make a deep and open technical discussion quite difficult to achieve; tutorial and commercial concerns would dominate. At the suggestion of Andrew Koenig, an “implementers workshop” was tagged on to the 1988 USENIX C++ conference in Denver. After the conference, a busload of conference speakers, C++ implementers, etc., set off from Denver to Estes Park for a day’s animated discussion. In particular, the ideas of static member functions (§13.4) and const member functions (§13.3) were so positively accepted that I decided to make these features part of Cfront 2.0, which was still delayed due to internal AT&T politics (§3.3.4). At my urging, Mike Miller presented a paper [Miller, 1988] that led to the first serious public discussion of exception handling in C++.

In addition to the USENIX C++ conferences, there are now many commercial and semi-commercial conferences devoted to C++, to C including C++, and to object-oriented programming including C++. In Europe, the Association of C and C++ Users (ACCU) also arranges conferences.

The first journal devoted to C++, The C++ Report, started appearing in January 1989 with Rob Murray as its editor. A larger and glossier quarterly The C++ Journal appeared in the spring of 1991 with Livleen Singh as editor. In addition, there are several newsletters controlled by C++ tools suppliers, and many journals such as Computer Language, The Journal of Object-Oriented Programming (JOOP), Dr. Dobbs Journal, The C Users’ Journal, and .EXE run regular columns or features on C++. Andrew Koenig’s column in JOOP is particularly consistent in its quality and lack of hype. The set of publications that discuss C++-related issues and their editorial policies change relatively fast. My purpose in mentioning journals, conferences, compilers, tools, etc., is not to give an up-to-date “consumer survey,” but to illustrate the breadth of the early C++ community.

Newsgroups and bulletin boards such as comp.lang.c++ on Usenet and c.plus.plus on BIX also produced tens of thousands of messages over the years to the delight and despair of their readers. Keeping up with what is written about C++ is currently more than a full-time job.

Until June 1988, all C++ compilers on PCs were Cfront ports. Then Zortech started shipping their compiler developed by Walter Bright in Seattle. The appearance of the Zortech compiler made C++ “real” for many PC-oriented people for the first time. More conservative people reserved judgment until the Borland C++ compiler was released in May 1990 or even until Microsoft’s C++ compiler emerged in March 1992. DEC released their first independently developed C++ compiler in February 1992, and IBM released their first independently developed C++ compiler in May 1992. There are now more than a dozen independently developed C++ compilers.

In addition to these compilers, Cfront ports seems to be everywhere. In particular, Sun, Hewlett-Packard, Centerline, ParcPlace, Glockenspiel, and Comeau Computing have shipped Cfront-based products on just about every platform.

C++ programming environments that are a match for the environments routinely supplied with other object-oriented languages are now emerging. For example, ObjectWorks for C++ from ParcPlace is essentially a Smalltalk program development environment adapted for C++, and Centerline C++ (formerly Saber C++) is an interpreter-based C++ environment inspired by the Interlisp environment. This gives C++ programmers the option of using the more whizzy, more expensive, and often more productive environments that have previously only been available for other languages, as research toys, or both. An environment is a framework in which tools can cooperate. There is now a host of such environments for C++. Most C++ implementations on PCs are compilers embedded in a framework of editors, tools, file systems, standard libraries, etc. MacApp and the Mac MPW is the Apple Mac version of that, ET++ is a public domain version in the style of the MacApp. Lucid’s Energize and Hewlett-Packard’s Softbench are yet other examples.

Though sophisticated beyond what has been generally used for C, these environments are only primitive forerunners of much more advanced systems. A well-written C++ program is a vast reservoir of information waiting to be used. Current tools tend to focus on syntactic aspects of the language, on the run-time properties of an execution, and on a textual view of the program. To deliver the full benefits of the C++ language, a programming environment must understand and use the full type system and escape the simple files-and-characters view of the static program representation. It must also be able to associate run-time information with the static structure of a program in a coherent manner. Naturally, such an environment must also scale to handle the large programs (for example, 500,000 lines of C++) where tools are of the greatest importance.

Several such systems are under development. I’m personally deeply involved with one such project [Murray, 1992] [Koenig, 1992]. I think a caveat is in place, though. A programming environment can be used by a supplier to lock users into a closed world of features, libraries, tools, and work patterns that cannot be easily transferred to other systems. Thus a user can become overly dependent on a single supplier and deprived of the opportunity to use machine architectures, libraries, databases, etc., that that supplier is disinclined to support. One of my major aims for C++ was to give users a choice of a variety of systems; a program development environment can be designed to compromise that aim, but it doesn’t have to [Stroustrup, 1987d]:

“Care must be taken to ensure that program source can be cost-effectively transferred between different such environments.”

In the same way as I see no hope for a single, grand, standard library, I see no hope for a single standard C++ software development environment [Stroustrup, 1987d]:

“For C++ at least, there will always be several different development and execution environments, and there will be radical differences between such environments. It would be unrealistic to expect a common execution environment for, say, an Intel 80286 and a Cray XMP, and equally unrealistic to expect a common program development environment for an individual researcher and for a team of 200 programmers engaged in large-scale development. It is also clear, however, that many techniques can be used to enhance both kinds of environments and that one must strive to exploit commonality wherever it makes sense.”

A multiplicity of libraries, run-time environments, and development environments are essential to support the range of C++ applications. This view guided the design of C++ as early as 1987; in fact, it is older yet. Its roots are in the view of C++ as a general-purpose language (§1.1, §4.2).

Thoughts about how C++ could be taught and used effectively by relative novices influenced the design of C++ from the earliest days. I did a lot of teaching – at least I did a lot of teaching for someone who is a researcher rather than a professional educator. My successes and failures in getting my ideas across and in seeing the real programs written by people I and others had taught strongly influenced the design of C++.

After a few years, an approach that emphasized concepts up front followed by an emphasis on the relationship between the concepts and the main language features emerged. Details of individual language features were left for people to learn if and when they needed to know them. Where that approach was found not to work, the language was modified to support it. The net effect was that the language grew to be a better tool for design.

The people I worked with and the people I taught tended to be professional programmers and designers who needed to learn on the job rather than taking weeks or months out of their lives to learn the new techniques. From this came much of the desire to design C++ so that it can be learned and its features adopted gradually. C++ is organized such that you can learn its concepts in a roughly linear order and gain practical benefits along the way. Importantly, you can gain benefits roughly in proportion to the effort expended.

I think the practical concern underlying many discussions about programming languages, language features, styles of programming, etc., has more to do with education than with programming language features as such. For many, the key question is:

If the answer for some other language is more satisfactory than for C++, that language will often be chosen because at this stage programmers usually have a choice (as they ought to have). In early 1993,1 answered the question on comp.lang.c++ like this:

“It is clear that to use C++ “best” in an arbitrary situation you need a deep understanding of many concepts and techniques, but that can only be achieved through years of study and experiment. It is little help to tell a novice (a novice with C++, typically not a novice with programming in general), first to gain a thorough understanding of C, Smalltalk, CLOS, Pascal, ML, Eiffel, assembler, capability-based systems, OODBMSs, program verification techniques, etc., and then apply the lessons learned to C++ on his or her next project. All of those topics are worthy of study and would – in the long run – help, but practical programmers (and students) cannot take years off from whatever they are doing for a comprehensive study of programming languages and techniques.

On the other hand, most novices understand that “a little knowledge is a dangerous thing” and would like some assurance that the little they can afford time to learn before/while starting their next project will be of help and not a distraction or a hindrance to the success of that project. They would also like to be confident that the little new they can absorb immediately can be part of a path that can lead to the more comprehensive understanding actually desired rather than an isolated skill leading nowhere further.

Naturally, more than one approach can fulfill these criteria and exactly which to choose depends on the individual’s background, immediate needs, and the time available. I think many educators, trainers, and posters to the net underestimate the importance of this: after all, it appears so much more cost effective – and easier -to “educate” people in large batches rather than bothering with individuals.

Consider a few common questions:

I don’t claim to have the only answers to these questions. As I said, the “right” answer depends on the circumstances. Most C++ textbook writers, teachers, and programmers have their own answers. My answers are based on years of programming in C++ and other languages, teaching short C++ design and programming courses (mainly to professional programmers), consulting about the introduction of and use of C++, discussing C++, and generally thinking about programming, design, and C++.

I don’t know C or C++, should I learn C first? No. Learn C++ first. The C subset of C++ is easier to learn for C/C++ novices and easier to use than C itself. The reason is that C++ provides better guarantees than C (through stronger type checking). In addition, C++ provides many minor features, such as operator new, that are notationally more convenient and less error-prone than their C alternatives. Thus, if you plan to learn C and C++ (or just C++), you shouldn’t take the detour through C. To use C well, you need to know tricks and techniques that aren’t anywhere near as important or common in C++ as they are in C. Good C textbooks tend (reasonably enough) to emphasize the techniques that you will need for completing major projects in C. Good C++ textbooks, on the other hand, emphasize techniques and features that lead to the use of C++ for data abstraction and object-oriented programming. Knowing the C++ constructs, their (lower-level) C alternatives are trivially learned (if necessary).

To show my inclinations: to learn C, use [Kernighan,1988] as the primary textbook; to learn C++, use [2nd]. Both books have the advantage of combining a tutorial presentation of language features and techniques with a complete reference manual. Both describe their respective languages rather than particular implementations and neither attempts to describe particular libraries shipped with particular implementations.

There are many other good textbooks and many other styles of presentation, but these are my favorites for comprehension of concepts and styles. It is always wise to look carefully at at least two sources of information to compensate for bias and possible shortcomings.

I want to do OOP, should I learn Smalltalk before C++? No. If you plan to use C++, learn C++. Languages such as C++, Smalltalk, Simula, CLOS, Eiffel, etc., each have their own view of the key notions of abstraction and inheritance and each supports them in slightly different ways to support different notions of design. Learning Smalltalk will certainly teach you valuable lessons, but it will not teach you how to write programs in C++. In fact, unless you have the time to learn and digest both the Smalltalk and the C++ concepts and techniques, using Smalltalk as a learning tool can lead to poor C++ designs.

Naturally, learning both C++ and Smalltalk so that you can draw from a wider field of experience and examples is the ideal, but people who haven’t taken the time to digest all the new ideas often end up “writing Smalltalk in C++,” that is, applying Smalltalk design notions that don’t fit well in C++. This can be as sub-optimal as writing C or Fortran in C++.

One reason often given for learning Smalltalk is that it is “pure” and thus forces people to think and program “object-oriented.” I will not go into the discussion of “purity” beyond mentioning that I think that a general-purpose programming language ought to and can support more than one programming style (paradigm).

The point here is that styles that are appropriate and well supported in Smalltalk are not necessarily appropriate for C++. In particular, a slavish following of Smalltalk style in C++ leads to inefficient, ugly, and hard-to-maintain C++ programs. The reason is that good C++ requires design that takes advantage of C++’s static type system rather than fights it. Smalltalk supports a dynamic type system (only) and that view translated into C++ leads to extensive unsafe and ugly casting.

I consider most casts in C++ programs signs of poor design. Some casts are essential, but most aren’t. In my experience, old-time C programmers using C++ and C++ programmers introduced to OOP through Smalltalk are among the heaviest users of casts of the kind that could have been avoided by more careful design.

In addition, Smalltalk encourages people to see inheritance as the sole or at least the primary way of organizing programs and to organize classes into single-rooted hierarchies. In C++, classes are types and inheritance is by no means the only means of organizing programs. In particular, templates are the primary means for representing container classes.

I am also deeply suspicious of arguments proclaiming the need to force people to write in an object-oriented style. People who don’t want to learn usually cannot be taught with reasonable effort. In my experience there is no shortage of people who do want to learn, and time and effort are better spent on those. Unless you manage to demonstrate the principle behind data abstraction and object-oriented programming, all you’ll get is inappropriate “baroque” misuses of the language features that support these notions – in C++, Smalltalk, or any other language.

See The C++ Programming (2nd Edition) [2nd] and in particular Chapter 12 for a more thorough discussion of the relationship between C++ language features and design.

Should I start using C++ as an OOPL or as a better C? That depends. Why do you want to start using C++? The answer to that question ought to determine the way you approach C++, not some one-size-fits-all philosophy. In my experience, the safest bet is to learn C++ bottom-up, that is, first learn the features C++ provides for traditional procedural programming, the better-C subset, then learn to use and appreciate the data abstraction features, and then learn to use class hierarchies to organize sets of related classes.

It is – in my opinion – dangerous to rush through the earlier stages because there is too high a probability of missing some key point.

For example, an experienced C programmer might consider the better-C subset of C “well-known” and skip the 100 pages or so of a textbook that describes it. However, in doing so the C programmer might miss the ability to overload functions, the difference between initialization and assignment, the use of operator new for allocation, the explanation of references, or some other minor feature in such a way that it will come back to haunt at a later stage where sufficient new concepts are in play to complicate matters. If the concepts used in the better-C subset are known the 100 pages will only take a couple of hours to read and some details will be interesting and useful. If not, the time spent is essential.

Some people have expressed fear that this “gradual approach” leads people to write in C-style forever. This is of course a possible outcome, but nowhere as likely as proponents of “pure” languages and proponents of the use of force in teaching programming like to believe. The key thing to realize is that using C++ well as a data abstraction and/or object-oriented language requires the understanding of a few new concepts that have no direct counterpart in languages such as C and Pascal.

C++ isn’t just a new syntax for expressing the same old ideas – at least not for most programmers. This implies a need for education, rather than mere training. New concepts have to be learned and mastered through practice. Old and well-tried habits of work have to be reevaluated. Rather than dashing off and doing things “the good old way” one must consider new ways – often doing things a new way will be harder and more time-consuming than the old way when tried for the first time.

The overwhelming experience is that taking the time and making the effort to learn the key data abstraction and object-oriented techniques is worthwhile for almost all programmers and yields benefits not just in the very long run but also within three to twelve months. There are benefits in using C++ without making this effort, but most benefits require the extra effort to learn new concepts – I wonder why anyone not willing to make that effort would switch to C++.

When approaching C++ for the first time or for the first time after some time, take the time to read a good textbook or a few well-chosen articles (The C+ + Report and The C++ Journal contain many). You may also want to look at the definition or the source code of some major library and consider the techniques and concepts used. This is also a good idea for people who have used C++ for some time. Many could do with a review of the concepts and techniques. Much has happened to C++ and its associated programming and design techniques since C++ first appeared. A quick comparison of the first and the second edition of The C+ + Programming Language should convince anyone of that.

How long does it take to learn C++? Again, that depends. It depends both on your experience and on what you mean by “learning C++.” The syntax and basics for writing C++ in the better-C style plus defining and using a few simple classes takes a week or two for most programmers. That’s the easy part. The main difficulty, and the most fun and gain, comes from mastering new design and programming techniques. Most experienced programmers I have talked with quote times from a half year to one and a half years before becoming really comfortable with C++ and the key data abstraction and object-oriented techniques it supports. That assumes that they learn on the job and stay productive – usually by programming in a “less adventurous” style of C++ during that period. If you could devote full time to learning C++, you would be comfortable faster, but without actual application of the new ideas on real projects that degree of comfort could be misleading. Object-oriented programming and object-oriented design are essentially practical rather than theoretical disciplines. Unapplied or applied only to toy examples, these ideas can become dangerous “religions.”

Note that learning C++ is then primarily learning programming and design techniques, not language details. Having worked through a good textbook I would suggest a book on design such as [Booch,1991], which has nice longish examples in five different languages (Ada, CLOS, C++, Smalltalk, and Object Pascal) and is therefore somewhat immune to the language bigotry that mars some design discussions†. The parts of the book I like best are the presentation of the design concepts and the example chapters.

Looking at design contrasts sharply with the approach of looking very carefully at the details of the definition of C++ – usually using the ARM which contains much useful information, but no information about how to write C++ programs. A focus on details can be very distracting and lead to poor use of the language. You wouldn’t try to learn a foreign language from a dictionary and grammar, would you?

When learning C++, it is essential to keep the key design notions in mind so that you don’t get lost in the language-technical details. That done, learning and using C++ can be both fun and productive. A little C++ can lead to significant benefits compared to C; further efforts to understand data abstraction and object-oriented techniques yield further benefits.”

This view is biased by the current state of affairs in tools and libraries. Given a more protective environment (for example, including extensive default run-time checks) and a small well-defined foundation library, you can move to the more adventurous uses of C++ earlier. This would allow a greater shift of the focus from C++ language features to the design and programming techniques C++ supports.

It is important to divert interest from syntax and the minute language-technical details where some long-time programmers like to poke around. Often, such interest is indistinguishable from an unwillingness to learn new programming techniques.

Similarly, in every course and on every project there is someone who just cannot believe that C++ features can be affordable and therefore sticks to the familiar and trusted C subset for future work. Only some actual numbers on performance of individual C++ features and of systems written in C++ (for example, [Russo, 1988] [Russo, 1990] [Keffer,1992]) have any hope of overcoming strongly held opinions to the effect that facilities more convenient than C’s must be unaffordable. Given the amount of hype and the number of unfulfilled promises in the languages and tools area people ought to be skeptical and demand evidence.

Every course and project also has someone who is convinced that efficiency doesn’t matter and proceeds to design systems of a generality that implies visible delays on even the most up-to-date hardware. Unfortunately, such delays are rarely noticeable for the toy programs people write while learning C++, so the problems with that attitude tend to be postponed until real projects. I’m still looking for a simple, yet realistic, problem that’ll bring a good workstation to its knees when solved in an overly general way. Such a problem would allow me to demonstrate the value of lean designs and thus counteract excess enthusiasm and wishful thinking in the way performance figures counteract excess caution and conservatism.

One aspect of C++ usage has repeatedly reasserted itself in my mind: a disproportionate number of C++ applications seemed to be odd in some way. This may of course simply reflect that unusual applications are more interesting to discuss, but I suspect a more fundamental reason. C++’s strength is in its flexibility, efficiency, and portability. This makes it a strong candidate for projects involving unusual hardware, unusual operating environments, or interfacing with several different languages. An example of such a project is a Wall Street system that needed to run on mainframes cooperating with COBOL code, on workstations cooperating with Fortran code, on PCs cooperating with C code, and on the network connecting all of them.

I think this reflects that C++ has been at the leading edge of industrial production code. In this, C++’s focus differs from languages with a bias towards experimental use – be it industrial or academic – or teaching. Naturally, C++ has been extensively used for experimental and exploratory work as well as for educational uses. However, its role in production code has typically been the deciding factor in design decisions.

Animation, autonomous submersible, billing systems (telecom), bowling alley control, circuit routing (telecom), CAD/CAM, chemical engineering process simulations, car dealership management, CASE, compilers, control panel software, cyclotron simulation and data processing, database systems, debuggers, decision support systems, digital photography processing, digital signal processing, electronic mail, embroidery machine control, expert systems, factory automation, financial reporting, flight mission telemetry, foreign exchange dealing (banking), funds transfer (banking), genealogy search software, gas station pump control and billing, graphics, hardware description, hospital records management, industrial robot control, instruction set simulation, interactive multi-media, magnetohydrodynamics, medical imaging, medical monitoring, missile guidance, mortgage company management (banking), networking, network management and maintenance systems (telecom), network monitoring (telecom), operating systems (real-time, distributed, workstation, mainframe, “fully object-oriented”), programming environments, superannuation (insurance), shock-wave physics simulation, slaughterhouse management, SLR camera software, switching software, test tools, trading systems (banking), transaction processing, transmissions systems (telecom), transport system fleet management, user-interfaces, video games, and virtual reality.

Ideally, people would choose the best language for each project and use many languages in the course of a year. In reality, most people don’t have the time to learn a new language to the point where it is an effective tool often enough to build up expertise in many languages. Because of that, even evaluating a programming language for an individual programmer or organization becomes a challenging task that is only rarely done well – and even less often documented in a dispassionate way that would be useful to others. In addition, organizations (for good and bad reasons) find it extraordinarily hard to manage mixed-language software development. This problem is exacerbated by language designers and implementers who don’t consider cooperation between code written in their language and other languages important.

To make matters worse, practical programmers need to evaluate a language as a tool rather than as simply an intellectual achievement. This implies looking at implementations, tools, various forms of performance, support organizations, libraries, educational support (books, journals, conferences, teachers, consultants), etc., both at their current state and their likely short-term development. Looking at the longer term is usually too hazardous because of the overpowering amount of commercial hype and wishful thinking.

In the early years, Modula-2 was by many considered a competitor to C++. However, until the commercial release of C++ in 1985, C++ could hardly be considered a competitor to any language, and by then Modula-2 seemed to me to have been largely outcompeted by C in the US. Later, it was popular to speculate about whether C++ or Objective C [Cox, 1986] was to be the object-oriented C. Ada was often a possible choice for organizations who might use C++. In addition, Smalltalk [Goldberg, 1983] and some object-oriented variant of Lisp [Kiczales,1992] would often be considered for applications that did not require hard-core systems work or maximum performance. Lately, some people have been comparing C++ with Eiffel [Meyer, 1988] and Modula-3 [Nelson, 1991] for some uses.

I have a deep respect for the strengths of C that most language experts don’t share. In my opinion, they are too blinded by C’s obvious flaws to see its strengths (§2.7). My strategy for dealing with C is simple: Do everything C does, do it as well as C or better in every way and everywhere C does it; in addition, provide significant services to real programmers that C doesn’t.

Fortran is harder to compete with. It has a dedicated following who – like a large fraction of C programmers – care little for programming languages or the finer points of computer science. They simply want to get their work done. That is often a reasonable attitude; their intellectual interests are focused elsewhere. Many Fortran compilers are excellent at generating efficient code for high-performance machines and that is often of crucial importance to Fortran users. The reason is partly Fortran’s lax anti-aliasing rules, partly that inlining of key mathematical subroutines is the norm on the machines that really matter, and partly the amount of raw effort and talent expended on the compilers. C++ has occasionally managed to compete successfully against Fortran, but rarely head-on in the crucial areas of high-performance scientific and engineering computation. This will happen. C++ compilers are becoming more mature and more aggressive in areas such as inlining. Fortran’s mature libraries are also being used directly from C++ programs.

C++ is increasingly being used for numerical and scientific work [Forslund,1990] [Budge, 1992] [Barton, 1994]. This has given rise to a number of extension proposals. Generally, these have been inspired by Fortran and haven’t been too successful. This reflects a desire to focus on abstraction mechanisms rather than specific language features. My hope is that focusing on higher-level features and optimization techniques will in the long run serve the scientific and numeric community better than simple addition of low-level Fortran features. I see C++ as a language for scientific computation and would like to support such work better than what is currently provided. The real question is not “if?” but “how?”

To this day, most of AT&T’s visibility in the C++ arena relies on Bell Labs’ traditional policy of encouraging developers and researchers to give talks, write papers, and attend conferences rather than on any deliberate policy to promote C++. Within AT&T, C++ was also a grass-roots movement without money or management clout. Naturally, coming from AT&T Bell Labs helps C++, but that help is earned the hard way by surviving in a large-company environment.

In competition with newer languages, C++’s fundamental strength is its ability to operate in a traditional environment (social and computer-wise), its run-time and space efficiency, the flexibility of its class concept, its low price, and its nonproprietary nature. Its weaknesses are some of the uglier parts inherited from C, its lack of spectacular new features (such as built-in database support), its lack of spectacular program development environments (only lately have the kind of environments that people take for granted with Smalltalk and Lisp become available for C++; see §7.1.5), its lack of standard libraries (only lately have major libraries become widely available for C++ – and they are not “standard;” see §8.4), and its lack of salesmen to balance the efforts of richer competitors. With C++’s recent dominance in the market the last factor has disappeared. Some C++ salesmen will undoubtedly embarrass the C++ community by emulating some of the sleazy tricks and unscrupulous practices that salesmen and admen have used to attempt to derail C++’s progress.

In competition with traditional languages, C++’s inheritance mechanism was a major plus. In competition with languages with inheritance, C++’s static type checking was a major plus. Of the languages mentioned, only Eiffel and Modula-3 combine the two in a way similar to C++. The revision of Ada, Ada9X, also provides inheritance.

C++ was designed to be a systems programming language and a language for applications that had a large systems-like component. This was the area my friends and I knew well. The decision not to compromise C++’s strengths in this area to broaden its appeal has been crucial in its success. Only time will tell if this has also compromised its ability to appeal to an even larger audience. I would not consider that a tragedy because I am not among those who think that a single language should be all things to all people. C++ already serves the community it was designed for well. However, I suspect that through the design of libraries, C++’s appeal will be very wide (§9.3).

No company language could succeed on the scale AT&T would like C++ to succeed. A proper implementation, tools, library, and education infrastructure is simply too costly for a single organization – however large – to afford. A company language would also tend to reflect company policy and politics, which could impede its ability to survive in a larger, more open, and freer world. In all, I suspect that any language that can survive both the internal strains of Bell Labs politics and the viciousness of the open market can’t be all bad – even if it is unlikely to follow the dictates of academic fashion.

Naturally, faceless corporations don’t just magically produce policies. Policy is formulated by people and agreement over policy is reached among people. The policy for C++ stemmed from ideas prevalent in Bell Lab’s Computer Science Research Center and elsewhere in AT&T. I was active in formulating the ideas as they related to C++, but I would have had no chance of getting C++ made widely available had notions of generally available software not been widely accepted.

Obviously, not everybody agreed all of the time. I was told that one manager once had the obvious idea of keeping C++ secret as a “competitive advantage” for AT&T. He was dissuaded by another manager who added, “Anyway, the issue is moot because Bjarne has already shipped 700 copies of the reference manual out of the company.” Those manuals were of course shipped with all proper permissions and at the encouragement of my management.

An important factor, both for and against C++, was the willingness of the C++ community to acknowledge C++’s many imperfections. This openness is reassuring to many who have become cynics from years of experience with the people and products of the software tools industry, but it is also infuriating to perfectionists and a fertile source for fair and not-so-fair criticism of C++. On balance, I think that tradition of throwing rocks at C++ within the C++ community has been a major advantage. It kept us honest, kept us busy improving the language and its tools, and kept the expectations of C++ users and would-be users realistic.

Some have expressed surprise that I discuss “commercial competition” without reference to specific language features, specific tools, release dates, marketing strategies, surveys, or commercial organizations. Partly, this is a result of being burned in language wars where proponents of various languages argue with religious fervor and by marketing campaigns where cynics rule. In both cases, intellectual honesty and facts are not at a premium and “debating” techniques I thought belonged only in fringe politics abound. Sadly, people often forget that there always will be a need for a variety of languages, for genuine niche languages, and for experimental languages. Praise for one language, say for C++, doesn’t imply a criticism of all other languages.

More importantly, my discussion of language choices is based on a belief that individual language features and individual tools are of little importance in the greater picture and serve only as a focus for pseudo-scientific skirmishes. Some variant of the law of large numbers is in effect.

All of the languages mentioned here can do the easy part of a project; so can C. All of the languages mentioned here can do the easy parts of a project more elegantly than C. Often, that doesn’t matter. What matters in the long run is whether all of a project can be done well in a language and whether all of the main projects that an organization – be it a company or a university department – encounters over a period of time can be handled well by that organization using that language.

The real competition is not a beauty contest between individual language features or even between complete language specifications, but a contest between user communities in all their aspects, all their diversity, and all their inventiveness. A well-organized user community united by a grand idea has a local advantage, but is in the longer run and in the larger picture at a severe disadvantage.

Elegance can be achieved at an unacceptable cost. The “elegant” language will eventually be discarded if the elegance is bought at the cost of restricting the application domain, at the expense of run-time or space efficiency, at the cost of restricting the range of systems a language can be used on, at the cost of techniques too alien for an organization to absorb, at the cost of dependence on a particular commercial organization, etc., The wide range of C++’s features, the diversity of its user community, and its ability to handle mundane details well is its real edge. The fact that C++ matches C in run-time efficiency rather than being two, three, or ten times slower also helps.

† Booch’s second edition [Booch,1993] uses C++ examples throughout.