In these exclusive interviews, Al Stevens talks with language pioneers Dennis Ritchie and Bjarne Stroupstrup about where C and C++ came from and more importantly, where they might be going.

January 01, 1989
URL:http://drdobbs.com/cpp/from-c-to-c-interviews-with-dennis-ritch/184408272

Dennis Ritchie is the designer of the C language and is the "R" in K&R, the nickname for The C Programming Language, co-authored by Brian Kernighan. He is a member of the Computing Science Research Center at AT&T Bell Laboratories in Murray Hill, New Jersey.

Dennis did his undergraduate and graduate work in physics and applied mathematics at Harvard University. Since joining Bell Lab's Computer Science Research Center in 1968, he has worked on the design of computer languages and operating systems. Along with others at Bell Labs, Dennis created the Unix operating system, and designed and implemented the C language. His current research is concerned with the structure of operating systems.

DDJ: As the designer of the C language, you are no doubt the world's very first C programmer in a world where the number of C programmers is inestimable and growing fast. Yet, certainly C was not your first language. When did your programming career begin and with what systems?

DR: I started when I was in college in 1961. I was a physics major. There was no such thing as a Computer Sciences curriculum then. The Comp Center at Harvard offered an informal course in programming on the Univac I, and I went to the IBM office and got manuals. In graduate school in 1963 I was the teaching fellow for the introductory programming course. For a while I worked at Project MAC at MIT. My graduate work was theoretical in recursive function theory. I lost interest in that aspect of things when I finished there, and I've been spending most of my time programming ever since.

DDJ: Do you actively program now?

DR: It depends what you mean by programming. There's a fair amount of looking at stuff and deciding how it should work. These days there's more bureaucratic stuff. I'm not in management, but I write memos, look at proposals, complain to the X3J11 C committee, and things like that. I'm definitely still involved in the technical aspects of things.

DDJ: The ANSI X3J11 committee has been five-plus years in arriving at a proposed standard for the C language. How long did it take you from the time you had your original idea for a C language until you had the first compiler running?

DR: The C language grew out of an earlier language. The syntax of the early C language was essentially that of B. Over the period of a couple of years it grew into something like its current form. The most significant milestone in the growth of the language was when the Unix system was rewritten in C.

DDJ: How long did that take?

DR: Mostly it was done in the summer. There were two tries at it. This was in 1973. The summer before, Ken Thompson tried to do it, and gave up. The single thing that made the difference was the addition of structures to the language. When he first tried there were no structures. They were in by the next summer, and this provided a way of encapsulating or describing the data structures within the operating system. Without that it was too much of a mess.

DDJ: You mentioned complaining to the ANSI X3J11 C committee. What was the extent of your participation in the development of the ANSI C standard?

DR: My participation in the committee was really quite minimal. I sent them a couple of letters. One was to point out the consequences and difficulties of the path they were taking with the new style function definitions and declarations. It's clear that the new style -- function prototypes, as they call them -- is a good thing. The language is better for having it, and it should have been done that way the first time. The problem, however, is in the interval before prototypes are universally accepted, while you still have both the old and new styles. I pointed out that with that approach there will be confusion and the possibility of errors. For example, if you think that there's a prototype in scope, you might call the function and expect that the arguments are going to be coerced as they would be in regular ANSI C. But it might not happen.

DDJ: In the Rationale document, X3J11 has paved the way to eventually do away with the old style of function declarations and definitions. Will that solve the problem?

DR: Yes, but in this interval there is a sticky situation. There are complicated rules for what happens when you mix the new and old styles. They covered all the bases when they made the rules, but the rules are messy, and most people couldn't reproduce them or explain what they mean. The letter I wrote was to suggest that maybe they should think about not doing it if only because it's too late, or as an alternative they should consider requiring an ANSI compiler to have the new style only.

My second letter was related to this "no alias" business that came up about a year and a half ago. I felt more strongly about this issue because I felt they were about to make a bad mistake, and I was willing to spend a lot of time getting them to reverse it.

Around December 1987, when they were intending to produce the penultimate draft, the one that had all the technical things in it (with possibly some language polishing needed, but nothing important), something that had been simmering a long time came to the boil. Some people wanted to put in a mechanism that would reduce the problems that optimizers have with aliasing.

Here's the problem. Suppose you have a single function that has two pointers as arguments, and the function can never be sure that the pointers might not point to the same thing. Or, suppose one of the pointers points to some external place. The function cannot tell where the pointers are going to clash. According to the language rules, this kind of thing is possible, and optimizers have to be very conservative about it. In most functions it might never happen, and so the conservative compiler will generate worse code than it would otherwise. Languages such as Fortran have an easier job of this because such aliasing is simply forbidden. There's no enforcement, of course, but the compiler can take an optimistic point of view. If your program doesn't work, someone can pull out the standard and say you shouldn't have done that. Aliasing was a plausible thing for the committee to think about. It does, in fact, make C somewhat harder to optimize. The mistake they made was in trying to design a facility to allow the programmer to say that a particular function has no aliasing problem. But they actually blew it. The language rules that they developed, even after many sessions of hard work, really just weren't correct. Their specification for how you say "no alias" was broken and would have been much more dangerous than not having it. If this had happened three or four years ago, people would have seen that this was wrong, fiddled with it, and either thrown it out or fixed it one way or the other. But this was supposed to be the next to the last draft, and all the technical requirements were supposed to be already done, and it was just broken.

That December I drafted a long and strongly worded letter to them saying that this just won't do, and pointed out the problems that I'd found. I even went to the meeting, the first X3J11 meeting I'd been to, and argued against it. What got me worried and annoyed was that this had happened when it did. If the thing had gone ahead it would have been a real bug in the specification. On the other hand, fixing it essentially meant a technical change, an important, non-editorial change, and they would need another long public review period. The point of view that I advanced was to get rid of it. I figured that my argument had to be simple to understand. If I had said, "This 'no alias' is broken, here's another thing that you should do instead," I could see us getting bogged down endlessly worrying about the technical details, so I figured it was better to argue that they should just throw it out altogether.

That was the only really detailed involvement I had with X3J11. The outcome was that there is no specification for "no alias." They voted it out. Except for some slight fiddles, the draft that is now before X3 is technically identical to what it was nearly two years ago.

Aside from those two issues, I left them alone for two reasons. One is that to take part in a standardization effort is an enormous amount of work. There are three one-week meetings a year all over the world, a lot of detailed reading, and I really didn't have the heart to do that. The second reason is that it became clear early in the proceedings that the committee was on the right track themselves. Their charter was to codify and to standardize the language as it existed. They decided in advance to do that and that is what they did. They did add some new things. The function prototypes are by far the most obvious, and there are a lot more minor things, but mainly they stuck to their charter.

I think they did a very good job, particularly when compared to the things that are happening in the Fortran committee, X3J3, where there are wide swings back and forth about the strange new things they're adding in, taking out, and putting back in. They have great political arguments between customers and vendors, Europeans versus North Americans, and it really seems to be a free-for-all. Even though some wrangling went on in the C committee, with the people involved seeming fairly fierce when you looked at it from outside, it's obvious that X3J11 was a comparatively tranquil and technically wise group.

The upshot is that I think they did a good job. Certainly, though, if I'd continued to work on things, some of the details would have been different.

DDJ: Are there any major areas where you disagree with the standard as it exists now?

DR: There are some obvious weaknesses. For example, they have never worked out what const really means. One of its intents is to say that this is some data that can be put into some read-only storage because it's never going to be modified. The definition that they have now is sufficient for that. But they also had other ideas about what it should mean, having to do with optimization, for example. The hope was that const is somehow a promise that the compiler could assume that the data item wouldn't change underfoot.

If you have a pointer to a const, one might hope that what is const is not going to suddenly change secretly. But, unfortunately, the way the rules read that's not actually true. It can change, and this wasn't just an oversight. In fact, they are potentially overloading the meaning of const. There are ideas involved other than what people hoped to get, and they never really worked out exactly which ones they wanted and which ones they didn't want. It's a little confusing.

It's generally recognized that the standardization of the library was as important as the standardization of the language. Among Unix systems there are few variations on what's available in the library. Most things are pretty much the same. In recent years, the use of C has spread far outside of Unix systems, and the libraries supplied with compilers tend to vary a lot, although many of them were based on what was available on Unix. So the standardization of the library is important. On the other hand, I've heard lots of complaints, both from users and implementors, that what they standardized and some of the rules and interfaces for library routines were not very well worked out. There may be more there than is necessary. Things got too complicated.

DDJ: What was the rationale behind the decision to leave out the read, write, open, close, and create functions?

DR: Those functions are viewed as being quite specific to the Unix system. Other operating systems might have great difficulty in supplying things that work the same way those do. The idea of the original pre-ANSI standard I/O library was to make it possible to implement those I/O routines in a variety of operating systems. It took us a couple of tries to reach that particular interface. The machines we had here were the PDP-11 running Unix, a Honeywell 6000 running GECOS, and some IBM 360s running various IBM systems. We wanted to have standard I/O routines that could be used in all the operating systems, even those that didn't have anything like Unix's read and write. The committee felt that it was better to let the IEEE and other Unix standardization groups handle that. They specifically avoided putting things in the C library that were Unix-specific unless they had meaning in other systems.

They did another thing that people don't quite understand. They explicitly laid out the name space that a standard compiler is allowed to usurp or claim. In particular, the guarantee is that there is a finite list of names that the compiler and the compiler system take up. These are simple names, beginning with underscore, and are listed in the back of the standard, something like keywords. You are allowed to use any name that isn't on this list. In an ANSI-conforming world, you are allowed to define your own routine called read or write and even run it on a Unix system. It's guaranteed that this will be your routine and that your use of the name does not conflict with any I/O that the library itself does on your behalf. The Unix library authors will be constrained to have an internal name for read that you can't see so that if you bring a C implementation from a big IBM machine or from an MS-DOS machine and you happen to use the name read for your own routine, it will still compile and run on a Unix system even though there's a system call named read. They have circumscribed the so-called name space pollution by saying that the system takes these names and no others.

DDJ: How can they be sure, that an implementor won't need other than those specific names from the list?

DR: There are rules for how the internal people can generate names, namely these underscore conventions. The end user is not allowed to use underscore names because any of these might be used internally. There is a problem, though. They made a list of things and said they'll do this and no more, and that helps. But there is still a problem for the writer of a library who wants to sell or distribute it. You're in a bind because you don't know all the underscore names that all the implementations are going to use. If you have your own internal names, you can't be sure that they're not going to conflict somewhere. If they have underscores, they might conflict with the underlying implementation. If they don't, then they might conflict with things that your end users are going to use. The C committee did not solve the problem that other languages have tackled explicitly. There are other ways of controlling the name space problem. They made a convention that helps, but it certainly didn't solve the real problem. It solved it enough to improve the situation. The basic problem with an uncontrolled name space is that if you write a program, and it just uses some name that you made up, it may be actually difficult to find out that this is not the same name as some random routine that's used internally by your system library. Unfortunately, we here at Bell Labs are in a bad position to notice this and do something about it because in our group we've simultaneously developed the compiler and the library and the Unix system, and so people here tend to know the names.

So, to summarize X3J11, the two largest things the committee did were function prototypes and the standardization of the library. It was more work than anybody expected, but I'm perfectly happy with what they did. The only problem was it took twice as long as they thought.

DDJ: Do you see a potential for other standard extensions to C, beyond those added by X3J11?

DR: One of the major excuses they give for not doing something is that there's no practice, no prior art. So obviously people will try to create prior art for the things they'd like to have happen. One such group is the Numerical C Extensions Group.

There are people who have strong views about what should happen. The idea is to get together with this group and agree that these are the things we need to have, so let's make some rules so that when people try things out, we'll all be trying it the same way, and we'll have a coherent story to tell, if there are going to be these extensions.

Most of them have to do with IEEE arithmetic issues, exceptions and such, for example. There's a core of things that are more general, and one that interests me is variable arrays with adjustable sizes. One of the things C does successfully is deal with single-dimension arrays that can be variable in size, but it doesn't deal with multi-dimensioned arrays that are variable at all. This is an important lack for numeric types, because it makes it hard to write library routines that manipulate arrays. Multiplying two arrays is a bit painful in C if the arrays are variable in size. You can do it but you have to program it in detail and the interface doesn't look pleasant. That's an obvious need, and I volunteered to look at how it might be done.

The NCEG will probably try to become official. They will affiliate themselves either with X3J11 or as an IEEE standardization organization. This would give them more clout. Also, many of the companies involved worry about legal issues. Companies who are members of informal groups deciding standards worry about anti-trust, whereas if they are members of official, blessed standards organizations, then they can contribute. They worry about being accused of going off into a corner and doing things behind other people's backs. It's better to do it in the open. This may be just some lawyer's nightmare. NCEG will probably become a subcommittee of X3J11.

DDJ: One non-ANSI extension to C is C++, a superset language that surrounds C with disciplines and paradigms that go beyond its original intent as a procedural language. Can you comment on how appropriate that is and how successful it has been?

DR: Let me confess at the start that I know less about C++ than I probably should. C is a very low-level language on a variety of fronts. The kinds of operations that it performs are quite basic. The control over names and visibility is basic. The defects or limitations of C in this area are most evident when you get into a large project where you need strong standards, rules, and mechanisms outside the language. Language developments such as C++ are trying to supply some of the structure within the rules of the language for controlled visibility of name space and are trying to encourage various kinds of modularization. This is good, I suppose.

C was designed in an environment where modularity was encouraged not so much by the language but by the kinds of programs we wrote. In the Unix system, the tradition is for small utilities that work together as tools, and the interfaces between them were set by the conventions and rules of the operating system, i.e., pipelines and so forth. The complexity of the pieces was kept low by custom. Commands tend to be simple. In the world today, there's a certain amount of admiration for that point of view. Certainly the appreciation for that style is part of the reason for the growth of Unix. People now are undertaking the building of much bigger systems, and things that we handled by convention ten or fifteen years ago must be handled by more explicit means. C++ is one such attempt.

Bjarne decided to design a compatible superset of C and to translate the C++ language into C code. That approach is not without its problems. First, having decided that C++ is going to be largely compatible with C, every time he departs from that he's under pressure either because of some accident or because ANSI changed something. Or because he feels that there's something he has to differ in, people are going to complain and get confused. Second, he is constrained by the choice to make a C++ to C translator possible, that is, he is constrained, as C was, by the existing tools of the various systems. The whole separate compilation business in C++ is made a lot harder by the desire to make it work with existing tools. If he could have simply designed a language and implemented it, then a lot of the anguish would have been avoided.

DDJ: Rumor is that within Bell Labs, C++ is now called C, and C is called "old C." Any truth in that?

DR: I've asked Bjarne not to say "old C," and, as far as I know, he has complied with that request.

DDJ: Colleges and universities have started offering courses in C. Some C tutors have observed that many instructors either don't understand C well enough or they don't understand teaching well enough to insulate the novice student from the kinds of things you can do in C, things that the student cannot grasp. In light of that, and as compared to Pascal, how do you view C as a potential teaching language?

DR: Obviously, C was never designed to be a teaching language. It was designed as a tool to express the kind of programs that we were trying to write at the time. And it's fairly low level in that concepts, like pointers, have a prominent role. I would not argue that C is a particularly good language for teaching programming. As Pascal was explicitly designed for that.

Pascal's main fault is that you cannot use Pascal originally designed to express all the things you need to, certainly not in a systems environment, and not for general applications either because of explicit constraints that are built into the language. C was, from the very start, designed to do all the things that we found necessary in order to express ourselves, and little design thought was given to preventing people from using its powerful features.

Nevertheless, it's possible to teach C in a way that's reasonably safe if you start with parts of the language that are similar to other procedural languages. Then you can teach C's more unusual aspects -- pointers, for example -- as cliches or set ways of expressing array manipulations and so forth. Later you can gradually widen out into the more general things possible with pointer manipulations.

I have not had the experience that the tutors have had. Part of the difficulty with being in a position like this is that you have very little opportunity to see what the novice really feels. But perhaps the reason there are not better instructors is that things have grown fast, and there might be people teaching C who only recently took the introductory course on the language themselves.

DDJ: Would you attempt a prediction for the future of the C language?

DR: I think the period of C's largest growth is over, although it will be increasingly used and it probably will not change very fast. The new language developments based on C will be on successors such as C++ or perhaps some things we haven't heard of. In terms of what C tried to do, I think it succeeded fairly well. The goals were reasonably modest. There's still plenty of work to be done finding languages that have the touch of reality that C has, work where you handle real problems in real environments as opposed to dealing with elegant creations that can't be used. Sometimes things can't be used just because the compilers don't exist on the machines people have. Sometimes it's because there are simply flaws in the design, not from the language point of view, but from the point of view of what the language ends up doing in the real world. And in that respect, C seems to have worn fairly well.

Bjarne Stroustrup is the creator of C++, the object-oriented extension to the C language. He is a researcher at the AT&T Bell Laboratories Computing Science Research Center where, in 1980, he began the development of the C++ extensions that add data abstraction, class hierarchies, and function and operator overloading to C. The C++ language has undergone several versions, and the latest is Version 2.0. Dr. Stroustrup maintains an active presence in all matters concerning the development, advancement, standardization, and use of C++.

DDJ: Many experts are predicting that C++ will be the next dominant software development platform, that it will essentially replace C.

BS: They're not alone. People were saying that five years ago.

DDJ: When you conceived the idea of C++ as an extension to the C language, were you thinking about object-oriented programming in the way it's come to be known, or were you looking to build a solution to a specific programming problem that would be supported by the features that you built into C++?

BS: Both. I had a specific problem. All good systems come when there is a genuine application in mind. I had written some simulations of distributed computer systems and was thinking about doing more of them. At the same time I was thinking about the problem of splitting Unix up to run on many CPUs. In both cases I decided that the problem was building greater modularity to get fire walls in place, and I couldn't do that with C. I had experience with Simula, writing rather complex simulations, so I knew the basic techniques of object-oriented programming and how it applied.

To solve the problem I added classes to C that were very much like Simula classes. That, of course, was the solution to a particular problem, but it included a fair amount of general knowledge about techniques, thoughts about complexity and management, complexity of modularity and all the baggage that you get from Simula. Simula is not ad hoc, especially not when it comes to the class concept, which is what I was interested in.

DDJ: Are you familiar with any of the PC ports to C++, specifically Zortech C++, Guidelines C++, and Intek C++?

BS: Only from talking to people and listening to discussions about them. They all sound good. The CFRONT ports, Intek and Guidelines, have the advantage of having the same bugs and features that you have on the bigger machines all the way up to the Cray, whereas Zortech has the advantage of being native to the PC world.

I walked around back in 1985 explaining why the current implementation of C++ couldn't be put on a PC. I designed the language under the assumption that you had one MIPS and one Meg available. Then one day I got fed up with explaining why it couldn't be done and did it instead. It was a pilot implementation, and it wasn't ever used, but I proved that it was possible, and people went and did the real ports. All the implementations are reasonably good, and they could all be better. Given time, they will be.

DDJ: Do the PC ports accurately implement C++ the way you have it designed?

BS: We do have a problem with portability from one machine to another. If you have a large program of ten to twenty thousand lines, it's going to take you a day to move from one independent implementation to another. We're working on that. Standardization is beginning. We're all sharing language manual drafts, and so it's trying to pull together. But a large program port will still take a day as compared to the ANSI standard ideal where you take something from a PC to a Cray and everything works. Of course, you never really get to that point even after full standardization.

DDJ: There are lots of rumors about Borland and Microsoft coming out with C++ compilers. Has any of this come to your attention?

BS: I've talked to people both from Microsoft and from Borland. They're both building a C++ compiler, and it sounds as if they're building it as close to the 2.0 specification as they jolly well know how to. Naturally, for their machines they'll need something like near and far, which is not standard language, but that's pretty harmless.

Both asked for a bit of advice and Microsoft asked for the reference manuals. I've talked to the Borland guys. I'm sad to say they didn't ask for a manual, but maybe they got one from other sources. The PC world is pretty cut-throat. Maybe people get the impression everybody is cut throat. That's not quite the case.

DDJ: One of the advantages of languages such as C and C++ is that they can be implemented on a wide range of machines ranging from PCs to Crays. With more and more people using PCs in their work, it's widely believed that acceptance in the PC world is what spelled the overwhelming success of C as the language of choice.

BS: That's widely believed in the PC world. In the minicomputer world it's widely believed that the PDP-11 and the VAX spelled the success of C and that is why the PC world picked it up. One of the reasons C was successful is that it was able to succeed in very diverse environments. There are enough languages that work in the PC world, enough that work in the minicomputer world, enough that work on the large machines. There where not very many languages that worked on all of them, and C as one of them. That's a major factor. People like to have their programs run everywhere without too many changes, and that's a feature of C. And it's a feature of C++.

DDJ: Do you see the PC as figuring as prominently in the acceptance of C++?

BS: Definitely. There are probably as many C++ users on PCs as on bigger systems. Most likely the number of PC users will be growing the fastest because the machines are smaller. People who would never use a PC for their professional work -- there are still a lot of those -- nevertheless like to play with things on a PC to see what it is, and that is where PCs come in. Similarly, if you are working on a PC, sooner or later you run into a bigger machine, and it's nice to be able to carry over your work. I'm very keen on portability.

DDJ: Do you have opinions as to whether preprocessing translators, such as the CFRONT implementation on Unix, have advantages over native compilers such as Zortech C++?

BS: It depends on what you're trying to do. When I built C++ I felt that I couldn't afford to have something that was hard to port, meaning it mustn't take more than a couple of days. I thought if I built a portable code generator myself, it would be less than optimal everywhere. So, I thought if I generate C, I could hijack everybody else's code generators.

For the last 40 years we've been looking for a universal intermediate language for compilation, and I think we've got it now, and it's called C. So, what I built was something that was a full compiler, full semantic check, full syntax check, and then used C as an intermediate representation. In essence I built a traditional two-pass compiler. And two-pass compilers have great advantages if you've got lots of code generators sitting around for them, and I had. They have the advantage that they tend to find errors faster than one-pass compilers because they don't start generating code until they have decided that the program looks all right. But they tend to be slow when they actually generate code. They also tend to be slightly larger and slightly slower throughout the whole process because they have to go through the standard intermediate form and out again.

And so, the advantages for the translator technology are roughly where you have lots of different machines and little manpower to do the ports. I see the one-pass compilers, the so-called native compilers, useful for machines and architectures where the manpower available for support and development is sufficient to make it worthwhile, which is when you've got enough users.

The two-pass strategy for translators was essential in the early days and will remain essential as long as new machine architectures and new systems come on the market so that you need to get a compiler up and running quickly. As the C++ use on a given system matures, you'll see the translators replaced by more specifically crafted compilers. On the PC, for example, CFRONT likes memory too much; it was built for a system where memory was cheap relative to CPU time. So once you know you are working for a specific architecture, you can do intelligent optimizations that the highly portable strategy that I was using simply mustn't attempt.

DDJ: Are there different debugging considerations when you are using a preprocessing translator?

BS: One of the things that people have said about the translators is that you can't do symbolic debugging. That's just plain wrong because the information is passed through to the second pass and you can do debugging of C++ at the source level. Using the 2.0 translator we're doing that. That 1.2 versions didn't have quite enough finesse to do it, and people didn't invest enough in modifying debuggers and the system-build operations to give good symbolic debugging. But now you have it.

DDJ: Can you estimate the worldwide C++ user base today?

BS: Fifty thousand plus, and growing fast, and that is a very conservative estimate.

DDJ: Have you formed plans to rewrite any or all of Unix with C++?

BS: Unfortunately, I haven't, despite that being one of my original thoughts. I've been bitten trying to write software that was too complex for the tools I had. When thinking about rewriting Unix, I decided that C wasn't up to the job. I diverted into tool building and never got out of that diversion. I know that there is an operating system written in C++ at the University of Illinois. It has a completely different kernel, but it runs Unix and you can make it look like System V, USD, or a mixture of the two by using different paths through the inheritance trees in C++. That's a totally object-oriented system built with C++. I know that AT&T and Sun have been talking about Unix System V, Release 5, and that there are projects working on things like operating systems rewrites, but whether they become real or not depends more on politics and higher corporate management than anything else. Why should we guess? All we can do is wait and see.

DDJ: Is what you do now primarily related to the development of C++ or the use of it?

BS: Both. I write a fair bit of code, still. I do a lot of writing, and I coordinate people, saying "Hey, you need to talk to that guy over there," then getting out of the loop fast. I do a fair bit of thinking about what else needs to be done with C++ and C++ tools, libraries and such.

DDJ: C is a language of functions, and a large part of the ANSI C standard is the standardization of the function library. C++ has all that as well and adds classes to the language. Is there a growing library of C++ classes that could eventually become part of a standard?

BS: The problem is there are several of them. We use some inside AT&T, and several of the other purveyors of C++ compilers and tools have their own libraries. The question is to what extent we can pull together for a standard library. I think that we can eventually get to a much larger standard library and much better than what is available and possible in C. Similarly, you can build tools that are better than what is possible with C because there is more information in the programs.

But people, when they say standards, tend to think about intergalactic standards, about things that are available in any implementation anywhere, and I think that they think too small. There are good reasons for differences between the ideal C++ environment for a Cray and the ideal C++ environment for a PC. The orientation will be different as will the emphasis on what is available. So we will see many standards, some for machine architectures, some over ranges of machines, some national standards. You could imagine the French having a whole series of libraries and tools that would be standard for people doing French word processing, for instance. You will see national standards, international standards, industry standards, departmental standards. A group building things like telephone operator control panels would have the standard libraries for everybody in the corporate department doing that kind of work. But a token standardization of everything, you won't see. The world is simply too big for that. But we can do much better than we're doing now.

DDJ: To the programmer, there is an event-driven or object-oriented appearance to the graphical user interfaces (X Windows, the Macintosh, Presentation Manager, MS-DOS Windows, and so on). These seem to be a natural fit for the class hierarchies of C++. How would these facilities be best implemented, and do you know of any recent efforts in these areas.?

BS: Some people have the idea that object-oriented really means graphics because there is such a nice fit. That has not been my traditional emphasis. The examples people have seen of object-oriented programming and object-oriented languages have, by and large, been fairly slow. Therefore, their use has been restricted to areas where there's a person sitting and interacting. People are relatively slow.

My first aims were in areas where you had complex programs that had a very high demand on CPU and memory, so that's where I aimed first. But people have been building very nice toolsets for doing user interfaces with C++. There is one from Stanford called "Interviews." Glockenspiel, in cooperation with Microsoft, is selling Common Views, which is a C++ toolset that looks and feels exactly the same whether you are under Presentation Manager, MS-DOS Windows, or on a Mac. There are C++ libraries for Open look.

The problem with all these so-called standards is that everybody seems to have their own standards, and then you start wondering how you can get toolsets that give platform independence across all of these I think that's one place where C++ comes in. Most of the differences between the major systems in the areas of text handling -- as opposed to high-performance graphics -- seem to be quite manageable as a common set of classes that could be standardized at the language level. It's certainly something that's worth exploring because the world is getting more fragmented.

DDJ: Are you familiar with Objective C, a C language extension that appears to do at least a subset of what C++ does, and how do the two languages compare?

BS: Vaguely. The company that sells it will claim that it does a superset of what C++ does, and that whatever C++ does that it does not, is not as important, naturally, I disagree. There is much higher emphasis in C++ on static type checking and on coherence of the type system. C++ is a rather large affair with multiple purveyors and multiple libraries, where objective C is a corporate language from a corporation that wants to make its fortune out of it. That places a different emphasis on everything.

DDJ: Concurrent C and Concurrent C++ are, like C++, extensions to the language. They add parallel processing operations to C and C++ for the development of multitasking programs that are portable among multitasking platforms. Do you have any comments on Concurrent C++? Is there a need for portable parallel processing, and do you think that Concurrent C++ fills that need?

BS: I don't like the idea of putting ADA tasking into C or C++. I think it solves the issues dealing with concurrency at the wrong level, sort of a medium-level thing. It doesn't give the transaction processing view and transaction logging that you need in data bases. It doesn't give the machine near world that you need when you write an operating system kernel or a real-time application. Personally, I don't like that approach at all. The approach I've taken with C++ is to provide con currency in the form of libraries. We have the Task Library that provides a much lower-level system that allows you to write multi-threaded programs. I've used it for simulations where I needed a couple of thousand processes or tasks and I want them to run with fairly minimal overhead. It has been used for robotics and such. I much prefer the library route over the route of adding syntax to the language. I think it serves more people better.

DDJ: Let's discuss the future of C++ and what programmers can expect in the next decade. The immediate future of C++ is, of course, 2.0, which adds multiple inheritance to the language. Can you summarize the other features added by version 2.0?

BS: It's a reworking of the language, polishing off the little rough corners, the unnecessary restrictions, and the problem areas we found. Even multiple inheritance can be seen as removing a little odd restriction, which was that you couldn't have more than one base class. We can argue how major an extension it is. Some people think it's major. I think it's sort of medium. It allows you to do things that you could do with C++ but noticeably cleaner and easier. I don't think it allows you to do anything radically new, and most of the other features I've added to 2.0 are of that ilk. It's meant to stabilize the language, it's meant to increase the quality of the implementations, and it's meant to remove unnecessary restrictions without destroying run-time or space efficiencies.

So, in version 2.0 you have the multiple inheritance, you have a more sensitive and better overloading resolution mechanism, you have type-safe linkage to make sure you can link larger programs together more effectively, and you have abstract classes. The list is fairly long but not radical. We have a lot of users, and we have to make sure there is a certain stability in the growth.

DDJ: Are you planning specific features for C++ beyond 2.0?

BS: We've been talking about exception handling and parameterized types for a long time. It's universally agreed that we need them. We have a reasonably good design for parameterized types that I presented at the last USENIX C++ conference, and that needs to be refined a little bit. Exception handling is one stage behind that, but we need it badly. When you go to C++, you get more ambitious. You want to have larger libraries, you want to use more of other people's code, and so you need more support. That's what we're trying to provide as quickly as we can without just throwing in everything at random. The language has to be kept coherent.

DDJ: The Integrated Development Environment with its integrated editor, compiler, and debugger has become the chosen software development suite in small systems. Turbo C, QuickC, Turbo Pascal, etc., are examples. Stand-alone symbolic debuggers that deal specifically with objects like C++ classes are beginning to appear as well. Are such environments appropriate for C++, and do you know of any current developments?

BS: Oh yes. They'll come. Some people will use them, and I believe you can buy one from ParcPlace now. I'll assume that since Microsoft is working on C++, they'll be working on a suitable environment. Borland is playing the same game they'll be doing it, too. I know of several other people who are thinking along those lines.

The thing that one has to seek is code portability across the different platforms. Certainly you can provide better tools for a specific platform, a better compiler, better compile times, a better program development environment. Unless, however, you are able to take your programs out of their environment and export them to something else, you have painted yourself into a corner.

DDJ: To date there is no standard for C++. Hewlett-Packard formally requested the ANSI X3J11 committee to undertake that standardization as a compatible superset of ANSI C, but the committee was ambivalent about it, failing to vote to begin the task. One reason for the request was to avoid the time-consuming overhead of setting up a new committee. Opponents to the idea pointed out that you are still in the process of the C++ definition and, as such, are not ready for standardization. Do you see the committee's action as an impediment to the acceptance of C++? Is C++ ready for standardization?

BS: Life isn't easy. Clearly we would like a fully standardized language, and equally clearly we don't know how to do that. There are still some features that we need to design. There were discussions that included me, other people at AT&T, and people from Hewlett-Packard and Microsoft. Where do we go from here, we asked? How can we get the most stable environment the fastest without freezing the language at a level where everybody has to extend it themselves? If we standardized C++ simply as it was, everybody would build their own exception handling and parameterized types.

I don't think that the ANSI C committee would be at all a suitable forum for standardizing C++. First of all, they are not C++ users. They may be C experts, but they are not C++ experts. We might as well say that since the Pascal committee did a good job on Pascal, let them do C++. We need a new commit tee composed of people with C++ experience. We clearly need a standard as soon as possible, but we simply have to figure out what "as soon as possible" means.

We need a C++ that's as compatible with ANSI C as possible, but it can't be one hundred percent compatible without destroying every C++ program ever written. When ANSI turned down the proposal, Hewlett-Packard went to SPARC, the policy committee for ANSI, with a new request to start a new ANSI C++ committee with the charter for standardizing C++, a committee composed of people who know the problems of exception handling and parameterized types, and who know that one hundred percent compatibility with ANSI C is not desirable -- as close as possible but no closer. That was accepted by SPARC, and they have sent a recommendation to X3 to start an ANSI C++ committee. Presumably the first meeting of that will be next spring.

DDJ: "As close as possible to C but no closer." That was the title of a paper by you and Andrew Koenig wherein you identified the differences between ANSI C and C++. The tone of the paper was that those differences are proper and necessary given the different purposes of the two languages. The paper also stresses the inconsequential nature of most of the differences. Do you see those differences as proof that C and C++ can not be combined? Should they be combined?

BS: I don't think the two languages should be reconciled further than they are. The differences are quite manageable by conditional expressions. If you are writing C++, you use the new keywords and it isn't ANSI. If you are writing ANSI C you could have an option in your compiler that suppresses the C++ subset, and it will not affect the way you write code. It's much more an issue for language lawyers than it is for programmers. The whole thing can be exhaustively discussed on two pages and the differences can be listed in about ten lines.

DDJ: Will you rewrite your book, the C++ Programming Language, to reflect the new features of version 2.0?

BS: I will as soon as I get time. But it's more important to get the language stabilized, and so I'm working on a new language definition, a new manual. I am working on a book, as well, with Margaret Ellis that explains what C++ is, not, as the first book does, how you go about using it. The book states what the language is, what the implementation techniques are that make sensible implementations of certain parts, and why certain decisions were made.

This is a "what" book, not a "how to" book. In theory, it's a book for experts. If you have a question about what the language is, the answer should be there. Lots of people prefer to learn languages from such explanations. You never know who would want something like that. I learned ALGOL 60 out of the ALGOL 60 Revised Report. I'm not the only one who is sort of semi-masochistic in the way I read things.

DDJ: When will this new book be available?

BS: It's supposed to happen in December or January. The question is whether I can make it. The manual work itself is taking longer than it should. It's about twice the size of the original manual, not because version 2.0 is twice the language as version 1.0, but because I need to go into much greater depth.

If you can assume your reader's culture, you can take shortcuts in explanations, and there are certain words that you can forget to define without getting into trouble. C++, however, is breaking out of the C ghetto. People who were brought up with Pascal and wouldn't touch C with a barge pole are getting on board with C++. They come in and they try to read some of the standard C++ literature. When you get their comments, you learn what assumptions you made without explaining them. Such things must not be done in the manuals we are working on. It's getting harder to write a manual because the audience is becoming more diverse.

DDJ: One of the problems we've observed when function-oriented programmers attempt the transition to object-oriented systems is that there doesn't seem to be any way to describe the new paradigm to them in a way that they can learn it without actually using it.

BS: We'll eventually do better. The first books on C++ just said what the language was, put a thin veneer on top of it, or described it primarily as a better C. Lipmann's book and Dewhurst and Stark's book go beyond that and demonstrate how things are done. We have a major education problem on our hands. I've been saying that for years. You can write Fortran in any language, and if you only use C++ as a better C, you'll see improvements in your programs and productivity, but you won't get anywhere near what you can do or what we have seen demonstrated with greater degrees of data abstraction and object-oriented programming.

DDJ: The function-oriented programmer does not understand intuitively what the advantage of that is.

BS: It's hard to explain how to bicycle. I can talk myself hoarse and still you go up to a bicycle, and you fall off the first time. A certain amount of practice must be done. Programming is an art like riding a bicycle. It's learned by doing it. But you can certainly help the process. You don't just say to somebody, "Here's a bicycle. Ride." Similarly we need better education on how to use a language like C++ for object oriented programming. You can write better articles, use videotapes, put training wheels on the new programming environments, help programmers get started. It can be managed. It will be managed. The gains in doing so have been demonstrated often enough.

DDJ: Programmers have been told that they must unlearn what they have learned in order to use object-oriented programming, and they reject that.

BS: That's not what I am telling them. C++ is a better C, and it supports data abstraction, and it supports object-oriented programming, and, yes, you can forget all you have learned and jump into the deep end. But lots of people do it differently. They start out using it like a better C, they experiment on the side with the techniques they don't quite understand. Follow the literature so that you know the syntax, the basic semantics, and your tools before you take that big leap. Then try to focus on classes for a new project.

One of the advantages of C++ is that you can take some of the preliminary steps without a paradigm shift from function to object-oriented programming. You can learn the tools, the language, the basics, how to use debuggers, whatever it takes. And then one day when you find the right project, you can try the next step. We've seen that done quite a few times.

There are people who enthusiastically read all the literature, go to C++ conferences, and then go straight in, design huge class hierarchies, and program them. I'm always amazed when it works, but it does quite often. There are people who can write perfectly standard designed C programs, go away and wait two months and come back and write their first program in C++, truly object-oriented with tens of thousands of lines, and, lo and behold, it works. By all laws, it oughtn't. But it's happened.

Of course, I'm sure there are also people out there who have gotten burnt trying to do that.

DDJ: Would you offer your comments about the future of programming. What kinds of things do we need to understand in order to deal with software development in the near future.

BS: I think we'll see much more emphasis on the design of classes and the formal interfaces between parts, and an increase in the reuse of existing programs and libraries of classes. We will need tools that help us do this and draw structure or draw inference on what the structure is. Things like performance analysis and coverage testing will all be available. It's worth remembering that it's not a solitary activity -- not just one guy sitting there with one machine; many of the key activities are social.

We'll also need to develop ways of talking about programs that are ahead of what we are doing today. It's no good if we can compose programs and components out of classes if we can't talk about that activity in a sensible way. We don't have the vocabulary. It would be nice if we knew what object oriented design was. By and large, we don't know it yet. But that will emerge in five years and will be virtually accepted almost universally after that.

Al is a contributing editor and columnist for DDJ and the author of a number of books on C.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.