SL: Thanks, it’s a pleasure to be here.

SL: Feature animations.

SL: I actually have three film credits. I have Hunchback, Hercules, and Mulan.

SL: I’m actually a union member of the Motion Picture Screen Cartoonists Union. And my latest title was Software Technical Director.

SL: You have to wait until the catering ... In fact, if you're with your children, you have to bribe them with promises of candy to get them to stay in the theater.

SL: Three parts are new in the book. Clearly there’s the new or modified language features -- namespaces, exception handling, the new cast notation and so on. There’s also the new Standard Library, and what used to be the Standard Template Library --the new string class, the complex number class. More importantly, in my opinion, there was a "re-imagining" of how I should present the material and of my understanding of how people use C++.

SL: Yes. In fact, one of hardest parts of starting the book was actually trying to rethink how one programs in C++. With pre-standard C++, you basically used new and delete and had to do all the memory management, particularly for container classes and dynamically allocating arrays. Most of that is now done automatically by the Standard Template Library. So, in a lot of ways, it’s a simpler language. You don’t have to deal with the lower level. Having a string class is a significant shift of paradigm as well.

SL: [The way I approached it in the book] was to try to, in each case, to think of a problem that needed to be solved, and then walk through a solution that was meant to illustrate a particular feature. So, for example, rather than simply present each of the 70 or so generic algorithms or present the container classes and their laundry lists of functions, I tried to present a problem and then show how those algorithms or containers can be used. So that [a user] starts thinking in terms of solutions and what’s available rather than simply getting hit with just a load of information you don’t know what to do with.

SL: Advanced. I’d say "advanced" in the sense that it’s information that somebody in an organization should know. But certainly in a first reading, or if you’re implementing or designing something, you don’t need to know it. The classic example is the overload function resolution semantics. Somebody should understand that, but everybody doesn't need to.

SL: Yes.

SL: Well, there’s two parts to this. You have to know some of the low level features, because you have to deal with C. For example, main() still takes a char * array. So, you have to deal with that. A lot of the file systems still deal with a char *. So, you have to show an array and a pointer. And pointer arithmetic. One of the major criticisms of C++ is that C++ is perceived as overly complicated, partly because people have tried to explain everything. This criticism is in part a result of our failure as teachers and presenters, I’m writing a book now that is an attempt to present C++ as a simple language.

SL: This is new book. I was working on it this morning. It is an attempt, in a sense, to manifest what Bjarne is saying: C++ can be a powerful and simple object-oriented and generic multi-paradigm programming language that can be explained in 250 pages.

SL: Right. C++ is a multi-paradigm language. Back in the early days of object-oriented programming, C++ was criticized for not being a pure language, like Smalltalk was. What we found was that in fact, one of the reasons it can be applied to so many different realms is that you can apply the particular paradigm that’s necessary. And a lot of times you don’t want to do object oriented. That’s something I tried to show in the book. I tried to show where just a simple abstract data type, or independent class works, or when the STL in generic programming. Generic programming is slightly amusing because it’s a 1970s kind of procedural paradigm. You have data out here and you have your functions here… That really goes against the object-oriented paradigm, if you will. Alex Stepanov, who invented [the STL], really doesn't think that object oriented programming is that important a paradigm and uses the STL as a model. So, we consider it a strength of the language to be able to move among paradigms. The main criticism of C++, of course, is that you could end up writing in C.

SL: That was Bill Joy's point, a long time ago. He said he liked C++ and at the same time also felt uncomfortable with it because it allowed the programmer to go to C, or to go to the bytes and bits. On one level, that’s important. When we were doing 2.0, back in ’87 and ’88, we tried to do away with the ability to cast away consts. We did that in a beta release and no one would use it because no one could get any of their programs to compile. Basically we should not diminish the C portion of C++. It’s part of the heritage. What we need to do is make the case for using the more elegant and more sophisticated design aspects of C++. The analogy I use is the difference between the Canadian Israeli borders. C++ does not prevent people from violating the tightness of the language.

SL: Well, this is no different than the old style Cast. The old style Cast is still supported...

SL: It’s explicit, but it’s still there. On eof the characteristics of C++ is that any mechanism can be suppressed or overridden. If you don’t want to use the virtual mechanism, you can override it. If you don’t want to use the template mechanism, you can create an explicit instant. If you don’t want to use the type system, you can cast it to a pointer.

SL: Well, there are two things to realize. In ’79, and ’80, what Bjarne needed to do was add the high level abstraction abilities provided by classes --encapsulation and public interfaces-- and introduce virtual functions. In "Design and Evolution", which I see on your table here, he mentions that back in the early ‘80s people didn’t see the value of virtual functions. C++ in the beginning required the passion and "buy-in" of C programmers. Many of the implementation designs that were introduced back in the original implementation, such as the location of the virtual pointer, for example, supported C programming. Microsoft, in the early ‘90s, moved the virtual pointer to the beginning of the object. That facilitates pointer to member functions and COM and certain things like that, but in a sense, it abandoned the C programmer.

SL: No, it’s not specified in the language. But what’s interesting is that in the early days we were concerned about supporting C and being able derive from a C struct to a C++ class. Again this is a very small detail, but it shows where our concern was.

At a certain point, everything turned around and we abandoned the C programmers. We focussed on object-oriented programming. The C declaration syntax and having seven kinds of integer types makes everything very complicated. But that’s where we came from, and, in a sense, there’s no point apologizing for one’s roots.

SL: It’s also a wonderful book in my opinion. Bjarne has always been, at least with me, very human. He allowed himself to show the struggles and fallibility’s of designing a language and learning from both mistakes and misconceptions sometimes. It’s an interesting book as a result of that. And of course, it also explains the language very well.

SL: The importance of the standard is twofold. It defines things that people need to know. When is a temporary destroyed, for example? It has a significant standard library. And that’s real important. Is it a perfect standard? Criticism is easy if you're on the outside. The standard doesn't have regular expression support, and as a result strings are harder to use than they should be. But people are aware of that. It was a question of being perfect and getting it done. It’s important to get it done, because there was a lot of implementation issues with compilers that are important to focus on. And it’s hard to focus on those while the language is moving.

SL: Actually it was a major insight to me. I think of it as a sort of Fairfield symmetry, if you will. I worked with Bjarne, Andy Koenig and other really smart people. We all understood the language reasonably well and when it was complicated, we understood why it was complicated, --to accommodate C, for example. When I moved to Disney, I found myself working with PhDs in graphics and mathematics who were, again, wonderfully smart, but they didn’t understand C++. They would actually program, if you will, "naively". I was suddenly stunned by difficult how C++ can be and by how it can become an obstacle to people getting their work done. As someone who’s taught C++ and presented it in the books, and a lot of these people used my book, I was concerned because I realized that we hadn’t really presented it correctly. Part of Bjarne and my own concern is to present it in a simpler way, so that it doesn't get in the way of people. And in a sense, that was the refocus of the "Primer".

SL: In the first chapter of his book, "Essential COM", Don Box talks about COM as a better C++. He mentions being able to make changes to classes and add interfaces without having to recompile. The irony is that all the design criteria for C++, and these were necessary at the time, were to make it fast and compact. For example, C++ has local objects, not just heap objects. Data members are offsets, and do not have to be accessed through a pointer indirect into the heap. C++ allows fast virtual calls by constraining the flexibility. These [design decisions] were a necessary precondition for object oriented programming to become mainstream, in my opinion, because it needed to prove itself at the time. Runtime type identification itself is constrained, in that it is only supported by polymorphic classes. A polymorphic class, in C++, has a virtual function.

SL: Right. It works very well. There is a runtime data structure and there’s a pointer to it.

One criticism of C++, for a long time, was that we didn’t support a type safe downcast -- going from a base class to derived class. The problem was that if we had introduced a general functionality, it would have penalized people that were just using C++ as either C or as independent data classes. So what Bjarne had to come up with a way of supporting two legitimate user bases: the procedural object base, concerned with speed and compactness and the object oriented base, concerned with flexibility. I think this exemplary of the language design principle. And he did that by saying, we’ll only give you runtime type identification if you’re a polymorphic class. Therefore, if you’re just a regular user and you just want to do pointer arithmetic on integers, there’s no penalty. If you just want to have a string class, an independent abstract data type, there’s no penalty. So, to answer you question, there’s a fundamental object model in C++ that was constrained not to be flexible in order to provide speed. A perfect example is sizeof. In a COM environment, sizeof is a runtime operation. In C++ and in C, it’s a compile time operation. If you want to be able to change the order of member data or add data types to a class and not have to recompile it, then those data members can’t be present in the object, and this represents an overhead, sometimes a significant overhead.

This a long answer to a short question, perhaps, but in order to not penalize users that don’t want that overhead, additions to the language would have to be constrained, and that would be difficult.

SL: Well, there are two points here. One of the great shames of the C++ industry, in my opinion, is that there hasn’t been any ability to get any agreement on a binary interface. And one of those simplest and, in a sense, most stupid examples of this is name encoding. Internally every compiler encodes names in its [proprietary way].

SL: Right. If you have two print functions that are overloaded, then you take the signature of the function. Every compiler encodes it differently. That clearly means that you can’t take code written from one compiler and move it to another. Or link it in, if you have a .o file. So people are constrained to distribute multiple .o files and executables. And this also applies to virtual function tables and virtual base classes. Sun was trying, with little success, to get a buyoff on a binary interface. And I think that’s to the detriment of the whole community. I don’t think there’s any excuse for that. So, that bothers me. I’m a little apart from the community now, so I can’t answer to that. But certainly that would go a long way.

SL: Right. I was talking with Andy Koenig who is the editor of the standard. Actually, I was complaining… There are really nice hash tables out there, made available by SGI and Alex Stepanov, but they’re not in the standard library. And that’s a shame. And the standard doesn't have regular expression for strings either. And that’s a real absence. It's important.

SL: It’s an interesting tradeoff. The problem is that you have to solve problems. I write a lot of Perl scripts at Disney. I can do the same functionality in C++, but it takes a lot more code and you have to dance a lot. And that’s a problem.

SL: Well, right. But I then have to make sure they have that library. They may have written their own. And then you have two incompatible ones.

SL: Well, I’m doing two things, by the way. I should mention it only for commercial reasons. One, I’m working on a two new books. The first one is an attempt to envision C++ as a simple, new language. I want it to be 250 pages. And the other one is part of Bjarne’s new in-depth C++ series on efficiency. The point that he’s trying to make is that a lot of C++ efficiency just comes from understanding the language. And the other thing I want to say is that my contract with Disney is lapsed, and so I’m actually [available for contract].

SL: Thanks for having me.

SL: Well, if I can say one thing… One of the goals of an author is to be able to get his name horizontally across the binding…

SL: And I’ve succeeded.