An Interview with C++ Creator Bjarne Stroustrup

→ I had long found the C++ books for beginners unsatisfactory, but I couldn't do anything about that because I didn't have sufficient experience with teaching beginners. Then, more than three years ago (after I had moved to Texas A&M University to become a professor), I was a bit too loud in expressing my opinion of the programming skills of students and what I saw as the lack of focus on programming in their curriculum. Someone asked if I thought I could do better and I had to deliver. I designed a course, delivered it again and again together with an experienced lecturer who saved me again and again from my inexperience and overambition. The current course and the book that goes with it is the result. We have now taught well over 1,000 students, so we know that the approach works.

My basic idea for the course was to list the knowledge and skills needed to start a project to produce code for the use of others than the programmers themselves. That list became the initial definition of the course. The point about "code for the use of others" is key. This leads to an emphasis on professionalism. When writing code that others rely on you need a responsible attitude to the structure of the code, the correctness ("how do you know it works?"), testing, and maintenance. It also implies that we can't let the student get stuck on obscure language-technical details (such as "exactly how does an unsigned short gets converted to an int?") beloved by teachers who like to set tricky tests. We have to get to the point where the students use object-oriented programming and generic programming because that's required for real-world applications. I also had to add something on graphics and GUI, but that's fun and helps in the appreciation of object-oriented techniques. Similarly, the STL features prominently to allow handling of data and to demonstrate generic programming techniques.

→There was far more direct feedback. Often, I was writing and making slides well into the night to have something for the students in the morning. Seeing a blank wall of faces is a great incentive to do better. Conversely, to see those faces light up is a very direct reward. Another difference is that I have had to think harder about what I wanted to communicate. I also had to articulate how to get the ideas across. The latter becomes essential when I don't teach all the classes myself. For a teaching approach to scale beyond what an individual can do, its aims, principles, techniques, etc. must be articulated.

I had to think hard about what I wanted to teach and how. Most people thought – and insist to keep thinking – that I was/am doing a C++ course. Actually, it is a course in programming. I use C++ to teach the principles and practical skills of programming. The teaching of programming language features is secondary. Obviously, C++ reflects my view of what programming should be so there is no major tension here, but I hope – and have reason to believe – that the skills can be applied with other languages.

When writing for beginners, you also have to provide more support than for professionals. So there are more exercises, more repetition, more emphasis, more summaries, more diagrams, and more color than people are used to from my other books. The style is ever so slightly lighter than in my other writing. However, it is still a demanding book. I did not set out to write the simplest book on programming because that would not teach people enough to be useful. My aim is eventual professionalism – the ability to write code others can rely on. Obviously, not all of my students will become programmers (I started out with electrical and computer engineers), but I do not want to give the impression that programming is a shallow art for dilettantes.

For many, my new book will actually be a second book on programming, but the first that aims at professionalism. I suspect that many will use the book for learning on their own, without the support of teachers and fellow students. That's hard, but I try to support that with detailed examples and condensed reference material. There is also material beyond what can be covered in a semester: text processing using regular expressions, numerical computation using an N-dimensional Matrix library, the basics of embedded systems programming, testing, and an overview of C programming from a C++ perspective.

→ Not really. I had done enough teaching at all levels – from middle school students to executives – even before I came to Texas that I had a pretty good idea what language ideas would help students. Unfortunately, the standards process is quite resistant to dramatic changes for the benefit of novices (of all backgrounds). The best thing that can be done for students is to provide more and better libraries. After that, anything that makes the language (and libraries) more consistent and less surprising helps.

In particular, I'd give a lot for a very simple graphics and GUI library, a simple library for accessing a few web resources, and (for my engineering students) a good linear algebra library. In my class, I supply the graphics and the matrices myself, but it would be so much better to use someone else's – especially to use standard versions.

However, we must be careful not to give the impression that calling other people's libraries is all there is to programming. One of the observations that influenced the design of my course and led me to present it as a book was repeated loud complaints from industry about the lack of capable systems programmers. Too many students graduate without exposure to the problems, tools, and constraints on solutions they will face in industry.

→ If all goes well, we'll vote out a standard in October. After that comes a public review period and time for dealing with the comments. After that comes a lot of standards bureaucracy procedures. Even if we deliver the text on time, it's touch and go whether the 'x' in C++0x will be '9'. I fear we'll have to go hexadecimal.

That said, I think that the new standard (C++0x) will be a boon to the C++ community in many ways. We'll have better tools for dealing with the (for most people) brave new world of concurrency. We'll have a few new libraries (regular expressions, hash tables, threads, etc.) and all the libraries will be easier to use and run faster thanks to new language features such as initializer lists, a more concise for loop, auto, etc.). Look at a few C++0x examples and consider what it would take to write them in C++98:

// C++0x code:


vector<string> v = { "Nygaard", "Kernighan", "Stepanov" };
unordered_map<string,int> index;		// hash table
for (auto p = v.begin(), p!=v.end; ++p) index[*p] = p-v.begin();

enum class Traffic_light { red, yellow, green }; 
enum class Alert_color { red, blue, green };
int red = 2; 
Alert_color c2 = red;		// error: no int to Alert_color conversion
Alert_color c2 = Traffic_light::red;	// error
Alert_color c2 = Alert_color::red;

template<Container C>	// concepts
      requires<Comparable<C::value_type>>
            void sort(T&);
sort(v);
sort(red);	// error: int is not a Container
vector<pair<string,int>> vp
       = { {"Nygaard",75}, { "Kernighan",66 }, {"Stepanov",57} };

sort(vp);	// error: pair<string,int> is not Comparable (no operator<)

Obviously, I'm restricting myself to tiny examples using the more obvious extensions. Note the absence of explanatory comments. Did you need any? It was hard for me that I could not use the C++0x in my new book. There are quite a few new features that help novices by simplifying notation and improving error handling.

→ No, there will not be nearly enough standard libraries for my taste. However, the C++0x will much more supportive than their C++98 counterparts. Simple C++0x library components, such as regular expressions, unordered maps (hash tables), and smart pointers are already being shipped by some vendors. The main contribution of the C++0x standard library will be to set concurrent programming on a firm basis with a machine model and a threads ABI . I would have liked support for higher level concurrency abstractions – directly using threads and locks is just about the worst way to try to exploit multi-cores. However, such higher-level support will come soon – standard or not – and the C++0x facilities provide a base. For example, the threading in Intel's TBB (Threading Building Blocks) is directly based on the (draft) C++0x threading ABI.

→ As ever: Performance, flexibility, generality, and access to hardware resources. When you encounter an application with "unusual requirements" you'll appreciate C++'s strengths compared to languages more finely tuned to a specific class of problems.

Actually, the interest in C++ seems to be increasing again. For example, the C++ track at the SD conference in Santa Clara in early March was by far the largest track and significantly larger than last year (where is again was larger than the year before).

→ Unfortunately, we can't do that. The committee cannot ban features that are used in innumerable programs and deprecation is widely ignored. Even the very few features we do manage to ban must be supported by implementers and the users complain bitterly about having to use compatibility switches. It is not easy to "be brave" with millions of lines of code and not responsible to "be brave" with hundreds of millions of lines of other people's code. So, I think that such "bravery" will have to wait for universal availability of near-perfect source-to-source translation tools. One of the advantages of a formally standardized language, such as C++, over proprietary languages is that the standard is a long-term commitment. Today's standard C++ will with absolutely minimal modifications run in 20 years, just as much 20-year old C++ does today.

→ It annoys me when I see recently written descriptions of C++ that would have been barely accurate in 1987. C++ was never meant to be just for OOP and certainly I never advertised it as such. See my publication list! Obviously, classical OOP still matters and will continue to do so. Kristen Nygaard (who invented OOP) used to comment that addition did not become useless or unused just because multiplication was invented and became fashionable. OOP serves a fundamental role that is not superseded by generic programming techniques. GP is currently fashionable and therefore over- and misused, but it is as fundamental as OOP and similarly has a permanent and prominent place in our programming and design tool chest. The interesting questions relate to exactly how to combine the two to get the best solutions for real-world problems (by "best" I mean things like correctness, maintainability, ability to reason about code, performance, and easy of reading and writing code). A classic example is the "draw all shapes" example that is usually seen as an example of object-oriented programming only:

	void draw_all(vector<Shape*> vs)
	{
		for(int i = 0; i<v.size(); ++i) vs[i]->draw();
	}

But note that we are already using generic programming here. That vector is a parameterized type. In C++0x, we can write that a bit cleaner:

	void draw_all(vector<Shape*> vs)
	{
		for (auto& x : vs) x->draw();
	}

However, we can also generalize draw_all() to apply to every data type that can be seen as a sequence:

    template<ForwardIterator Iter>
          requires SameType<Iter::value_type,Shape*>
    void draw_all(Iter b, Iter e)
	{
          for_each(b,e, [] (Shape* p) { p->draw(); });
	}

Here, I again used C++0x features. In particular, I used concepts to get good type checking and the lambda notation for defining the operation to be applied to each element of a sequence. However, the point is that this is clearly generic programming that after a bit of conventional type manipulation invokes a virtual function on a class hierarchy. This is a prototype for a common and very general style of "mixed OOP and GP code" which (if you must) you can call multi-paradigm.

We could call draw_all() like this:

vector<Shape*> v = { new Circle({0,0},10), new Triangle(p1,p2,p3) };
draw_all(v.begin(),v.end());

set<Shape*> s = { new Elipses({0,0},10,20), new Square({10,10},p3) };
draw_all(s.begin(),s.end());

→Denmark is a wonderful country that it is easy to be homesick for. It's a small country where most natural and cultural phenomena are on a human scale. It helps that it's also a rich, stable country running a full welfare state at a consistent profit. I miss my friends and family – but email and the web editions of Danish newspapers help me keep in touch. I miss the food – but I can get herring, salami, cheese, etc. airlifted in from a Danish shop in California. Danes are rather fond of food – I feel an affinity to Tolkien's hobbits. Danes tend to be significantly more trusting than Americans – I miss that. On the other hand, I could not have done my work in Denmark. Something on the scale of Bell Labs could not be built and sustained in Denmark.

→I'm thinking about that. I have to write a 4^th edition, but it is non-trivial to decide what it should be. Each edition has had a separate aim and scope as the C++ community evolved. Including the standard libraries, the C++0x standard might come close to 2,000 pages. I don't think my 4^th editions should compete with that in either style or size.