The C++ Programming Language, Third Edition

The Annotated C++ Reference Manual

The Design and
Evolution of C++

Design and Use of C++ by Bjarne Stroustrup

Talk given November 3, 1997 at Computer Literacy Bookstore in San Jose, CA

Bjarne Stroustrup is the creator of the C++ language and a graduate of the University of Aarhus, Denmark and Cambridge University, England. He is currently the head of AT&T Labs’ Large-scale Programming Research Department and is an AT&T Bell Laboratories Fellow. Dr. Stroustrup is the author of Annotated C++ Reference Manual, The Design and Evolution of C++ and the newly revised classic C++ Programming Language, 3rd Edition.

Introduction
On behalf of Computer Literacy Bookshops and the San Francisco Area Center for Advanced Technology, I'd like to welcome you to tonight's event. I'd like to introduce Marian Corcoran, CEO and Founder of the San Francisco Bay Area Center for Advanced Technology, who will introduce tonight's speaker.

Good evening. I would like to introduce Bjarne Stroustrup, the designer and original implementer of C++. He is the author of The C++ Programming Language, first, second, and third editions; The Annotated C++ Reference Manual, often called ARM; the Design and Evolution of C++, which is one of my favorite books of all time. He's a graduate of Cambridge University with a Ph.D. in Computer Science. He's the head of AT&T Labs Large-Scale Programming Research Department and an AT&T Bell Labs Fellow. His interests are distributed systems, operating systems, simulated distributed design and programming. I now give you Dr. Bjarne Stroustrup.

Slide #1
Design and Use of C++: Q&A session.
Bjarne Stroustrup
AT&T Labs
Florham Park, NJ 07932, USA
bs@research.att.com
http://www.research.att.com/~bs

Dr. Stroustrup's Opening Comments
Good evening. At the end of next week, we'll have an ISO C++ standard! Next week, the ANSI and ISO committees meet in Morristown, New Jersey, and unless something completely unexpected happens, we'll adopt a national and international standard. So, when asked "When will the C++ standard be finished?" I can asnwer" Next friday at 10:30. This is an important event for the C++ community, so I thought, I'd just tell you before starting on my prepared comments. Note: Dr. Stroustrup's prediction came through: That friday the standard was approved by unanimous vote; see a press release from the ISO C++ standards committee]

Slide #2: Overview
What are programming languages for?
 - why care which programming language is used?
 - why care about programming?
C++'s design criteria
 - language, not system
 - efficiency & abstraction
An example
 - read and sort
 - the importance of style

Learning C++
First, I'm going to talk for about twenty minutes, to set a few themes. I'm going to say a little bit about what programming languages are for - partly because I'm always befuddled about why people fight so much over them. After all, they're just programming languages. Then, I'm going to say a little bit about what I think C++ is and should be. Finally, I'm going to show a few code samples of the sort you might see on the first day of a C++ course because I think education is an absolutely key issue in programming and system building today.

Slide #3: Why would anyone care what programming language was used to implement a system?
User's view:
 - I don't care how you build it as long as it works and is cheap.
 - When can I get it?
System supplier/vendor's view:
 - When can I get it?
 - How do we test it?
 - How do we maintain it?
 - How do we install it?
 - How do we predict things about it?
 - Does it have lots of neat features?
Programmer's view:
 - ???
 - (why/how should/does a programmer's view matter?)

One question that you may like think a little about is why would anybody care which programming language you use? I mean, the user can't see what language you used. Even if he could, he shouldn't, in my opinion. I don't have to know in detail how the engine of my car works. If, when driving a car, I can recognize what engine it has, there's something wrong with that engine. It's intruding itself on my consciousness in a way it's not supposed to. I just want to drive a car, I don't want to know which programming language was used to program its fuel injectors. I don't care; I want it to work; I want it to be cheap; and I preferably want it delivered yesterday.

System suppliers have a whole list of questions that they are interested in. The suppliers resemble users, to a certain extent, but they have slightly more detailed views.

Programmers have a lot of opinions, as you all know, but why do their opinions matter? Why, as non-programmers, should we care? I think that, as programmers, we ought to have a good answer to that question, because if it doesn't matter, then the managers are right in just hiring the cheapest people they can find and telling them exactly what to do and how to do it. We ought to have a higher degree of professionalism. We can only do that if we can answer simple questions like this.

Slide #4: Style of code matters for program structure.
Internal structure:
- unseen by end users
- key to maintainability, extensibility, portability, testability, ...
A programming language can support a clean internal structure by:
- making it easier to express that structure
- automating frequent tasks
- allowing the programmer to create new "concepts"
- making that structure explicit
- helps understanding
- makes programs more amenable to analysis

My answer is that the style of code matters because it helps us to express program structure. The internal structure of a program is crucial. It is unseen, by the user, but it is what determines how you can maintain things, how you can change things to fit new conditions, for different computers, for different user communities, and for different natural languages. If my program has to run in Finland, its users might object to having it spew English text. Or if I'd written it to produce Danish, which would come naturally to me, you might find it annoyingly hard to understand.

All of these issues - the maintainability, the extensibility, the portability - depend on internal structure. Internal structure can be enhanced or obscured by a language. That's why our programming technique and our programming languages matter. My conjecture is that a programming language can support a clean internal structure by making it easier to express that structure. If we have to write in, say, hexadecimal machine code, we might have an idea, but that idea is unlikely to come unmodified into the code. As we raise the level of programming languages, and when we provide more facilities for expressing structure, there's a greater chance that the structure is actually in the code the way we thought about it in design.

We can also automate frequent tasks. There are lots of boring,unpleasant things that you'd rather not do if you could help it. In theold days you had to load the registers yourself before you could add values. And you had to say whether you were adding integers or floating point numbers. After a day you could have written a thousand instructions and they worked. After an effort like that you could feel good - I actually love writing assembler. However, I think if you can write a couple of thousand lines of code in a day, then there's typically something wrong. You should have had a neat little tool that helped you to get it done in half an hour. You don't want to do simple mechanical tasks by hand just because you can do them easily.

I think a programming language must allow you do more than its designers envision. That is, you can't build a language that has built-in all the neat things you would ever need. And this, of course, is what most commercial organizations try to do: to give you exactly what you want. No more, no less. I think it is impossible to give people all they need. No designer, no organization can know enough about the needs of system builders to put in everything. Therefore, extensibility becomes crucial.

In this case, I expressed it as "programmers have to create their own concepts." These concepts are are expressed by things like classes, modules, templates - whatever they're called in various languages. So, this is one thing a language can do. The second is simply to make a concepts explicit so that it can be seen.

I don't know if you're experience with code generators that allow you to work from a very high level but generate low-level code from which you can't get back to the high level again. In that case, you have to maintain some rather unpleasant machine-generated code in a low-level language. I don't like that myself. Most of the time, I'm not actually writing code. I'm trying to figure out what the code is doing, either my code or somebody else's code.

I like a language to help by making the code more amenable to analysis. An optimizer is simply something that analyzes the code to figure out how to remove inefficiencies from it. You can have analyzers that create dependency graphs, you can have analyzers that find atypical structures, non-idiomatic expressions. You want as much help as you can get when building systems, and a programming language can help by making it possible to write programs that analyze our code.

These are some of my first level, and most important, most fundamental issues. As usual, discussion of really fundamental issues are somewhat indistinguishable from arm waving. So, I'll go down one level and get to something that I know a bit about: how and why did C++ came about?

Slide #5
Original idea: combine C's strengths as a systems programming language with Simula's facilities for program organizations

My comments about programming languages in general are both the starting point of C++ and my conclusion from years of work with C++. I had the fundamental notions before I started C++, and I learned much more over the years.

Here's the original idea about C++. I wanted C's strength for a systems programming language, and I wanted Simula's facilities for program organization.

Simula is the source of most of what we call object-oriented programming and object-oriented design these days. It's a very interesting language, and when you look back, its designers (Dahl and Nygaard) had a clear feeling, not just of language issues and programming issues, but also of the design issues. They saw the programming language in the context of the design techniques. I think that's something that is very, very often forgotten in the haste of getting the next release out.

Unfortunately, having gotten a fair bit of experience with Simula,I found I simply couldn't afford to run my programs written in it. Then, I came to the conclusion that I did not want to have the choice between writing code that's elegant and code that is efficient. C++ is an attempt to ensure that I can do most things elegantly, and that most of the things that I can do elegantly, I can also afford to use. For things I'm doing, C++ is a pretty good approximation to that ideal.

Slide #6: C with Classes - why C?
The best systems programming language available:
- flexible, efficient, portable
- available, known
- 2nd order flaws not critical

but: improve static type checking

When C++ first came about, I called it "C with classes." C because C was the best systems programming language around: it was efficient, it was portable, it was very flexible. It was available, and it was known.

C was not as well know as it is today, however. A lot of people asked: "C? Why didn't you use Pascal like everybody else?" My answer was, "Well, I don't like Pascal. It's a straitjacket. I'm not looking for a straitjacket, I'm looking for flexibility, efficiency, portability and so on." Some, then said: ""But, C's pretty awful"." My answer to that was: "No, no. C has some pretty awful parts. I don't like the sloppy type checking; I don't like its declarative syntax; I don't like the conversion rules for built-in types. However, these are second-order issues. I've never noticed that these things stop people from writing a good program. On the other hand, I have seen an overly rigid type system stopping people from writing a good program. In particular, Pascal has stopped me from writing good programs. So, these problems with C are second-order things which you can deal with."

However, one of the first things I did to build C with Classes from C++ was to improve the static type system because I don't really want "sqrt(2)" to mean "segment violation." I would like to make sure that run-time errors happen as infrequently as possible.

Slide #7: C with Classes - why Classes?
- program organization
- mapping of concepts
      - a class is a type
      - static checking

The other part of "C with Classes" that became C++ was the classes; the Simula aspects of program organization; the notion that you write code by figuring out what your concepts are, and mapping them into classes in your program; taking the view that a class is a type, and static checking.

I just mentioned that I found Pascal's static checking unpleasant and unhelpful. It took me some time to realize why stronger static checking in Simula didn't bother me at all. The reason is that the Simula type system is extensible and flexible. So, what this static type checking does is to check my rules for my (user-defined) types, rather than some language designer's rules for the built-in types he provided. And that makes all the difference. If you have an extensible system, you don't have a straitjacket, you have an enforcement of your own rules. This is a radical difference.

Slide #8: C++ Design Rules
- C++'s evolution must be driven by real problems.
- C++ must be useful now.
- C++ is a language, not a complete system.
- Provide comprehensive support for each supported style.
- Don't try to force people.
- All features must be affordable.
- It is more important to allow a useful feature than to prevent every misuse.
- No implicit violations of the static type system.
- Provide as good support for user-defined types as for built-in types.

Over the years, a fair number of rules came about for the design of C++. You can't just sit down and design a language. As soon as you have a little bit of success, everybody comes and want the language to be stable except for two things they absolutely want added to it. So, you can't not just design the language, sort of from day to day. You have to slowly build up a set of rules by which you live. Rules allows you to say "yes, your suggestions are very nice ideas, but the rules I operate under are these, and those suggestions don't quite fit."

I consider theory a great constraint on solutions. But it's not a good guide to choosing the problems you want to solve. So, you look for real problems or you wait for real problems to come to you. Then, you use all the relevant theory you can find to make sure that the solution you choose fits this problem.

There has been a fair amount of thinking about these great languages we'll need to solve these great problems we get in a few years for these great machines we'll have in a few years, and for these programmers that are so much smarter than the "dumb folk who are programming now." I decided that I know the machines I've got now, I know my friends that are writing programs, I know the problems they're dealing with, and the systems they use. Maybe I can do something to help - and I'll leave the far future to people who have working crystal balls. So, in designing C++, I tried to deal with problems that I knew, current problems, and I tried to make C++ useful now. I supported my first non-research user six months after I started C with classes.

Another thing I decided was, that I was designing a programming language, not an operating system, not a filing system, not a user interface system, etc., etc. There are a lot of questions you can't ask about C++, like "what's a binary file?" It's not a language issue, it's a system issue. On the other hand, we can take C++ and use it on a variety of systems. I found that aspect of C++ particularly useful for writing code in the areas where you might not have an operating system. I'm not sure that a fuel injector has been programmed in C++, but I know there's a lot of gadgetry that you can carry around in your hand that has.

Slide #9: C++ is a Better C
- supports data abstraction
- supports object-oriented programming
- supports generic programming

The net effect of all of this is that C++ is a better C - meaning that it is a language where you do the things you usually do in C, in better ways, without additional overhead and without restrictions on what you can do. It supports data abstraction - the notion of having concepts represented directly. It supports object-oriented programming - from Simula in form of class hierarchies and use of such hierarchies. And it supports generic programming - the ability to parameterize types and functions with other types, which is very useful.

Slide #10

// Simple program:

int main()

{

// read numbers

// sort numbers

// output mean median

}

// Typical for introductory texts

// Common activity in real code

//      read input doing something to each element

//      do something with all elements

//      the exact number of input values is unknown

I'll take questions now.

Question and Answer

Q: Why does C++ not have a realloc?

A:  Well, it has a realloc, if you use malloc, which you shouldn't. But, basically, you don't need realloc in C++ because the standard data containers, such as vectors and lists, expand with the technique I just showed you. So instead of declaring a simple array, figuring out you've run out of space, and then try to realloc, you simply use a vector that keeps expanding as needed. This, of course, is implemented at a lower level using something that looks rather like realloc. But it is far less error-prone and usually more efficient. Most people don't seem to realize that realloc moves every element, sometimes. They get bitten by when they have pointer into the array, then they realloc the array, and then they get surprised the array moved. So, yes, you can use malloc/realloc in C++, but you shouldn't. And you needn't because this is a better facility - there are safer and more convenient ways of getting the same thing done.

Q: In the language Common LISP there is a notion of closure in which one writes an ad hoc function, that has a lot of lexical context at the point of the function generation. And its proper use is to pass this function around...

A:  I know what a closure is, and there are dialects of C with nested functions that try to get to that idea. C++, standard C++, does not have closures or nested functions and won't get them, at least not for the next five or ten years. Part of the problem is how to define the context well enough, and part of the problem is that you can get too much context and get obscure code. That at least is the traditional answer in the C++ and C world. And in a lot of areas that is a reasonable answer.On the other hand, there's a lot of algorithms where it's nice to have the equivalent of closure. The simplest case is a "for each" in which you do something to all elements of a sequence. Another example is taking the sum of a set of elements; where you get the context to put the sum in and return it? Compare two sets. How do you specify what is the comparison criteria? In C++, you generally use an object that acts like a function when give to an algorithm such as for_each, accumulate, or compare. This is directly supported in the standard library, is through "function objects." Somebody calls them "functors." There's a variety of names for them, but basically, you define a class of which you can initialize objects. This initialization explicitly gives an object its initial state. That is, you don't pick up the context, where a context is everything that could affect you. You initialize an object with a specific set of elements (from the context) that defines what the object can refer to. Then, you go and apply the call operator on the object, and at the end of the algorithm you can call any of the functions that you have defined for that object to extract information from it. That way you can pass a fair bit of context through many iterations, for instance. So, there are no closures in C++, and no nested functions. However, there are function objects that in many areas serve the same purpose. Functional objects allow us to approximate some function or programming techniques. And actually do it fairly elegantly and very efficiently.

Q: So now that machines are fast, how hard is it to run LISP? Also, Java has a garbage collector; is that going to be offered in a future version?

A:  Machines have become faster every year for the last about 40 years or so. My experience is that the only thing that grows faster than hardware cycles is human expectation. I think that throwing away a factor of 5, 10, 30, 50 of efficiency is acceptable in some areas. But there are many areas where it is not acceptable. Traditionally, I have been most interested in applications that are rather demanding on time or space, and for those the basic efficiency of a programming language matters.

Essentially, I think there are three parts to your question. One is the machine efficiency, another is LISP, and the third is garbage collection. I think they are separate issues. I am sure that today there are many things that you could do in LISP that you couldn't get away with doing in LISP ten years ago. LISP happens not to be my favorite language for most of the things that I'm doing. But clearly the hardware improvements help all languages including LISP. I think there's some very nice aspects of LISP that have been quietly forgotten or maybe people have been ruling out LISP for other reasons.

Now, garbage collection is a much more interesting issue. If you like garbage collection, it's usually because you are doing things where you can afford it. And I'm sure we can afford it in many more applications than people think. If I wanted a garbage collector language, I would, out of personal inclination, probably use C++. There are pretty good garbage collectors available for C++. They're pretty good, meaning at least as good as what you can get for any other language. And they work.

I tried to get the standards committee to write into the text the fact that garbage collection could be used and document two or three positions that has to be explicit for using garbage collection in C++. The third of the C++ committee that really likes C, had conniptions. Therefore the fact that garbage collection is a valid implementation technique for C++ is still implicit in the standard.

There is nothing in C++ that prohibits garbage collection. Various people, such as me, have been going around saying that you can actually do it for about 15 years. You can get a very nice free garbage collector and you can also get commercial ones if you need support and things like that. My guess is that we'll see significant experimentations of different garbage collectors with C++ in the next few years. It's already happening.

Q: Now, if I can just add on to that question... perhaps the largest remaining weakness in C++ is the fact that it started out in C, and there are still various stages of C in the language that are unpleasant. Have you got any thoughts on when C++ is finished, designing a successor language that may correct some of those things? High on my list would be pointer arithmetic.

A:  In the early years of C++, I used to go around with a slide that had two lists: advantages and disadvantages. You found C prominent in both columns. There's no doubt that some of the main problems that people have had with C++ has to do with its C heritage. On the other hand, there is no doubt that some of the things that attract people the most - and are seen as most important by a lot of people - is the C heritage. I am opposed to anything that decreases the compatibility between C and C++. I hope that the C community will have a similar attitude toward C++.

I have no plans of going to another language. I think that people that go and build general purpose programming languages must be nuts. It's a field that has essentially a zero success rate, and if you - against the odds - have any degree of success you get wrapped up in a lot of unpleasant work. Or, you get wrapped up in some commercial unpleasantness and hype that warps peoples' brains. My only excuse for getting into the language design business is that I didn't mean to. I had some specific problems that I looked for solutions for: that's how C++ came about. Should I do another language, it would be because I've gotten myself into a hole that didn't know any other way out of. I am not in such a hole now.

I think for real problems the conversion rules between the various integer types ranks very high on my list of annoyances in C and C++. For sheer annoyance, the syntax also comes high. But the syntax you get used to after a week. The only people I really worry about are people who are proud that the can write things like the definition of a function returning a pointer functions without using a typedef or looking in a manual. When things like that become an issue of pride, there's something wrong. I think that the C's model of arrays and pointers is actually very fundamental, has a very good match to real hardware, so I don't particularly want to throw that away. So I would think very hard before doing something like that, but I don't have to think very hard because I'm probably not going to touch it.

Q: You talked about extensibility as being important for C++, and for the evolution of C++... have you done any thinking about having the structures, the actual programmatic structures being extensible as well, such as in languages like Forth, where you can create your own if-thens?

A:  I thought about that a long time ago in several contexts. I wouldd very much have liked to integrate a variety of control structures. I was working on concurrency at the time and I was also thinking of having a more flexible expression syntax. Consequently, I looked at languages where you could define control structures. That was about fifteen years ago. I looked at the examples that the designers put forward as good examples. I found them hard to read. That was discouraging. I talked to people who had written in a language where they could define their own control structures and operators. Basically, they said: "don't do it." And so I set out to design a language that was extensible, but not mutable. Yes, it was a deliberate design decision.

By the way, since I'm in a bookstore, I guess I should point out that I have yet to answer a question that is not answered in this book (The Design and Evolution of C++). I took the time a few years ago to actually sit down and think what is this, why is it here, how did it come about, and to write it down.

Q: How would you compare C++ to Java?

A:  I will answer one question about Java. And I'll try to give a reasonably exhaustive answer, instead of getting into all kinds of lengthy discussions. Before there was Java there have been other languages that offered similar facilities - Smalltalk, Modula-3, Eiffel and such. So Java doesn't look as new to me as it does to some people. I dislike hype rather strongly. And I think Java is floating on hype. I dislike proprietary corporate languages rather strongly and Java is one of those. So that might color my answer a bit.