Abstract: an attractive visit of C++. The vision of the language is up-to-date, e.g. on STL. I appreciate the quasi-systematic use of handles instead of pointers. It is a good documentation of a spiral design process: the interfaces are developed stepwise, and converge towards stable (but minimal) ones (e.g. Chapter 10). The book doesn't pretend to cover all of C++, but may be a nice entry point (chock therapy?) by showing what can be done in C++. I still wonder why is virtual inheritance not mentioned.
Excerpts:
p 24, 2.1.2 Software factories?
Some people treat the overhead of big projects as inevitable. The result of such treatment is a plethora of complicated systems to manage this overhead. All too often, however, the result of such management is merely well-organized overhead. It's still there; it's just been put in neat boxes and charts and thus it seams easy to understand. Some people revel in this overhead. They behave as if it is a Good Thing -almost as if the overhead is really the cause of productive software development, rather than something standing in the way. After all, if control and organization are good, more control and organization must be better.
p 27, 2.2.3 Abstraction and memory management
[...] garbage collection reclaims only memory: It does not affect other resources. C++ takes another, more unusual route: Its constructors and destructors allow the designer of a data structure that needs dynamic resource allocation to specify exactly how the resources associated with that structure should be freed.
[...] Treated abstractly, many data structures have notions of initialization and termination that extend well beyond mere memory allocation.
p 127, 11.2.3 Not all classes are general
We usually think of a class as having an interface, which consists of its public members, and an implementation, which comprises everything else.
p 174, 14.6 Discussion
Once you have put in the effort to design an abstraction that does what you want, you have effectively added a new word to your vocabulary.
p 252, 21.7 Implementation [Syntax of template ctor of template class in an
example]
template <class X, class Y>
template <class F, class G>
Composition<X, Y>::Composition(F f, G g):
p(new Comp<F, G, X, Y>(f, g) {}
p 356, 31.5 Class libraries and language semantics
[...] the value of a variable in C++ is a far more general notion than it is in C or in other languages. C++ allows for the possibility that a variable may somehow "own" some resource that must be given up when that variable changes value.
p 357, 31.6 Making things easy is hard
Writing C++ classes is an example of doing user interface design, and doing good user interface design is hard.
From a posting in comp.object, on 22 Sep 1996
We are honored this month to have an interview with Andy Koenig of AT&T Research. He has authored many articles in C++ Report and JOOPS and is the editor for the working draft of the X3J16 ANSI C++ Committee. I always find his work to have depth and insight.
1. I'm always interested in the background of a book. How did this book come about? What was the motivation for writing it?
Just as ‘C Traps and Pitfalls’ started out as a Bell Labs technical report, ‘Ruminations on C++’ started out as a series of articles in the (then) newly formed ‘Journal of Object-Oriented Programming.’When Rick Friedman started that magazine, he asked Bjarne Stroustrup if he would write a column for it. Bjarne decided he had too many other irons in the fire, but suggested that I might be interested. When Rick asked me if I would write the column, I said yes -- but with the clear understanding that I intended eventually to make those columns into a book.
Of course, merely having a bunch of magazine columns is not, by itself, a good enough reason to publish a book. From time to time, various people tried to convince me to slap a pair of covers on a collection of columns and publish the result, but that didn't seem fair. People who read the book should come away with more than if they just read a bunch of individual columns -- else why bother with the book at all? So, just as it was clear from the beginning that the columns would someday form the basis for a book, it was also clear that a substantial rewrite would be needed. Barbara really provided the impetus for that, as well as doing much of the rewriting.
2. What are the major issues in the book and why did you select those topics? For example, a number of chapters in the book discusses the Standard Template Library (STL) and libraries in general. Why address these issues now? (Optional: How is your treatment of these issues different from what can be found elsewhere?)
Barbara did the selection, and fit them into a coherent structure. Of the hundred or so columns I wrote, she picked about a third of them. Sometimes she coalesced several columns into one. Sometimes she asked me to write columns on specific topics, with an eye toward filling what would otherwise have been gaps in the book. Sometimes she wrote additional material herself. In a few cases she found things I had written that had never been published elsewhere. Once she had put together an initial collection, we both went over it until we were both reasonably satisfied. Then we started rewriting. And rewriting. And rewriting some more. It really is true that once you think a book is finished, you're halfway done.Why address the STL, and libraries in general, now? If not now, when? Although I have generally been conservative when discussing language features, libraries are a different matter -- because it is usually easy to start using libraries without having to install a new compiler. This is particularly true of STL. Once Hewlett-Packard released source code for an initial implementation, anyone who wanted to do so could start using it. Thus it made sense to talk about STL long before talking about, say, namespaces.
Other people have written about STL, of course, and more will follow. But I think the book approach to STL is unusual in the same way that its approach to the rest of the language is unusual: It focuses on using sensible examples to understand the main concepts. Once you know the concepts, you can read a reference manual and know why the various components are there.
3. In the beginning of the book, you have a chapter "Why I Use C++", and you demonstrate in code how the abstraction of the class helps simplify an operating system programming problem. If you were going to write something on "Why I Use STL", what would you say?
I wouldn't have much to say. It would be like asking me why I use iostreams. STL is now an integral part of C++. If you are writing a C++ program, and you want variable-length vectors, you have three choices: use the STL vector class, use a non-standard library class, or write your own.Maybe that's begging the question. Perhaps the question I should answer is ‘Why I cajoled the standards committee into accepting STL as part of the standard library.’ In which case, the answer would be that it was the only library proposal on the table that had a unifying architecture behind it, and therefore the only proposal that would give users a framework that they could use to add their own classes to the structure.
The great strength of STL is that you can write your own containers, which will work with the standard algorithms, and you can write your own algorithms, which will work not only with the standard containers, but also with my containers.
Even if you're not writing your own containers or algorithms, STL offers a family of containers that work the same way whenever it makes sense for them to do so. For example, you can use the same code to reverse the elements of a vector or a list. Most other libraries don't work that way.
4. Some time ago, I wrote to Bjarne Stroustrup asking him for material that would give greater insight into the C++ language, and he recommended your articles in JOOPs (Journal of Object-Oriented Programming.) Often, you have insights, or seem to be able to "see" and help develop a new technology, not yet well understood. Can you explain your approach to this type of thing, perhaps citing an example from the book ... how your ideas developed?
5. (Optional) What is the "unit from hell"?
I'd like to answer both of those questions at once.The ‘unit from hell’ is the name that Barbara gave to the material that ultimately wound up as Chapter 16 (‘Templates as Interfaces’) after she volunteered to teach that particular material at the course we give at Stanford each summer. It is the hardest chapter in the book, but it is an important chapter because it introduces an important idea.
That idea, in turn, came from what has been a source of insight in a number of my articles: looking at how to solve problems in other languages and finding C++ equivalents for those techniques. I'm not talking merely about translating programs from one language to another, but rather about understanding what's really going on in one language and then finding analogous ideas in another language.
The idea in the ‘unit from hell’ is that it is possible to describe interfaces independently of the particular things to which they interface. That is, it is possible to talk about how to do something without necessarily saying what it is that you are doing. The chapter uses the example of fetching consecutive elements from a sequence without saying just how those elements are stored.
There is little new about separating interface and implementation this way, but this particular way of expressing it was new to C++ at the time I wrote the article. In this case, I got the idea from two other programming languages: Smalltalk and ML.
Smalltalk is a more thoroughly object-oriented language than C++, in the sense that just about everything is an object. That means that the natural way to express interfaces in Smalltalk is through abstract base classes. ML, on the other hand, is not object oriented at all. It has no notion of inheritance. Nevertheless, it has a way to talk about interfaces explicitly, by allowing programmers to define something called a ‘signature’ that describes a collection of related types and functions.
One problem; two solutions in two languages. At the time I wrote ‘Templates as Interfaces,’ the Smalltalk approach was the ‘obvious’ way to solve that problem in C++. So I started thinking about the question: Was there a way to express the ML solution in C++?
C++ has no notion of an interface as a separate entity in the language. One uses classes to express concepts in C++. So my first step was to try to use a class to express an interface. But ML interfaces could have type parameters (this is a slight oversimplification, but the idea is right). So to express that idea in C++, I would need a way of giving type parameters to classes as well. But that was exactly what templates did. The problem, then, was to figure out how to use templates to achieve the same ends in C++ as signatures do in ML. After that key insight, the rest was not difficult.
Of course, to have that insight at all, I had to know two other languages aside from C++. A lot of my insights come from thinking in other programming languages, even if I do not always express them that way.
6. In chapter 11, you give some important information on virtual functions, cost of calling them in different ways, and demonstrate how to create a class which uses a virtual function, but reduces the overhead by the way it is designed. Many of our readers are software professionals working in industry. Such programming techniques or understanding of C++ is very important to the success of their work. What other things are covered in the book which would be of value to further their programming ability?
There is relatively little in the book about code optimization, partly because such optimizations are often system dependent, but almost everything in the book is intended to help people become better programmers. I learned a lot while writing it.
7. Is there anything else you think it is important to say that I haven't already asked?
We reprinted the dictionary definition of ‘ruminate’ on the copyright page because English is not everyone's first language.The woman on the front cover is (deliberately) not anyone we know.
The cats in the back cover picture are named Snobol and Rocky. Snobol is the black one; she deserves her name because she is a good string manipulator. Rocky looks like a raccoon. Her picture is a little weird because she is looking at the ceiling. I have no idea what caught her attention while Dag was photographing us.
I hope there will be a ‘C++ Traps and Pitfalls’ book someday. I haven't started writing it yet, but when I do, the columns by that name in the ‘C++ Report’ will be a good start.