Chapter 0: Notes to the Reader - Bjarne Stroustrup's Homepage

1

0

Notes to the Reader

“When the terrain disagrees with the map,trust the terrain.”

—Swiss army proverb

This chapter is a grab bag of information; it aims to give you

an idea of what to expect from the rest of the book. Please

skim through it and read what you find interesting. A teacher

will find most parts immediately useful. If you are reading this

book without the benefit of a good teacher, please don’t try to

read and understand everything in this chapter; just look at “The

structure of this book” and the first part of the “A philosophy of

teaching and learning” sections. You may want to return and

reread this chapter once you feel comfortable writing and execut-

ing small programs.

004_stroustrup_fm04_ch00_bk 11/19/2008 2:44 PM Page 1

0.1 The structure of this book0.1.1 General approach0.1.2 Drills, exercises, etc.0.1.3 What comes after this book?

0.2 A philosophy of teaching andlearning0.2.1 The order of topics0.2.2 Programming and programming

language0.2.3 Portability

0.3 Programming and computer science

0.4 Creativity and problem solving

0.5 Request for feedback

0.6 References

0.7 Biographies

0.1 The structure of this bookThis book consists of four parts and a collection of appendices:

• Part I, “The Basics,” presents the fundamental concepts and techniques ofprogramming together with the C++ language and library facilitiesneeded to get started writing code. This includes the type system, arith-metic operations, control structures, error handling, and the design, im-plementation, and use of functions and user-defined types.

• Part II, “Input and Output,” describes how to get numeric and text datafrom the keyboard and from files, and how to produce correspondingoutput to the screen and to files. Then, it shows how to present numericdata, text, and geometric shapes as graphical output, and how to getinput into a program from a graphical user interface (GUI).

• Part III, “Data and Algorithms,” focuses on the C++ standard library’s con-tainers and algorithms framework (the STL, standard template library).It shows how containers (such as vector, list, and map) are implemented(using pointers, arrays, dynamic memory, exceptions, and templates)and used. It also demonstrates the design and use of standard library al-gorithms (such as sort, find, and inner_product).

• Part IV, “Broadening the View,” offers a perspective on programmingthrough a discussion of ideals and history, through examples (such asmatrix computation, text manipulation, testing, and embedded systemsprogramming), and through a brief description of the C language.

• Appendices provide useful information that doesn’t fit into a tutorial presen-tation, such as surveys of C++ language and standard library facilities,and descriptions of how to get started with an integrated development en-vironment (IDE) and a graphical user interface (GUI) library.

CHAPTER 0 • NOTES TO THE READER2


0.1 THE STRUCTURE OF THIS BOOK 3

Unfortunately, the world of programming doesn’t really fall into four cleanly sep-arated parts. Therefore, the “parts” of this book provide only a coarse classifica-tion of topics. We consider it a useful classification (obviously, or we wouldn’thave used it), but reality has a way of escaping neat classifications. For example,we need to use input operations far sooner than we can give a thorough explana-tion of C++ standard I/O streams (input/output streams). Where the set of topicsneeded to present an idea conflicts with the overall classification, we explain theminimum needed for a good presentation, rather than just referring to the com-plete explanation elsewhere. Rigid classifications work much better for manualsthan for tutorials.

The order of topics is determined by programming techniques, rather thanprogramming language features; see §0.2. For a presentation organized aroundlanguage features, see Appendix A.

To ease review and to help you if you miss a key point during a first readingwhere you have yet to discover which kind of information is crucial, we placethree kinds of “alert markers” in the margin:

• Blue: concepts and techniques (this paragraph is an example of that)• Green: advice• Red: warning

0.1.1 General approachIn this book, we address you directly. That is simpler and clearer than the con-ventional “professional” indirect form of address, as found in most scientific pa-pers. By “you” we mean “you, the reader,” and by “we” we refer either to“ourselves, the author and teachers,” or to you and us working together througha problem, as we might have done had we been in the same room.

This book is designed to be read chapter by chapter from the beginning tothe end. Often, you’ll want to go back to look at something a second or a thirdtime. In fact, that’s the only sensible approach, as you’ll always dash past somedetails that you don’t yet see the point in. In such cases, you’ll eventually go backagain. However, despite the index and the cross-references, this is not a book thatyou can open on any page and start reading with any expectation of success.Each section and each chapter assume understanding of what came before.

Each chapter is a reasonably self-contained unit, meant to be read in “one sit-ting” (logically, if not always feasible on a student’s tight schedule). That’s onemajor criterion for separating the text into chapters. Other criteria include that achapter is a suitable unit for drills and exercises and that each chapter presentssome specific concept, idea, or technique. This plurality of criteria has left a fewchapters uncomfortably long, so please don’t take “in one sitting” too literally. Inparticular, once you have thought about the review questions, done the drill, and


CHAPTER 0 • NOTES TO THE READER4

worked on a few exercises, you’ll often find that you have to go back to reread afew sections and that several days have gone by. We have clustered the chaptersinto “parts” focused on a major topic, such as input/output. These parts makegood units of review.

Common praise for a textbook is “It answered all my questions just as Ithought of them!” That’s an ideal for minor technical questions, and early read-ers have observed the phenomenon with this book. However, that cannot be thewhole ideal. We raise questions that a novice would probably not think of. Weaim to ask and answer questions that you need to consider to write quality soft-ware for the use of others. Learning to ask the right (often hard) questions is anessential part of learning to think as a programmer. Asking only the easy and ob-vious questions would make you feel good, but it wouldn’t help make you a pro-grammer.

We try to respect your intelligence and to be considerate about your time. Inour presentation, we aim for professionalism rather than cuteness, and we’drather understate a point than hype it. We try not to exaggerate the importanceof a programming technique or a language feature, but please don’t underesti-mate a simple statement like “This is often useful.” If we quietly emphasize thatsomething is important, we mean that you’ll sooner or later waste days if youdon’t master it. Our use of humor is more limited than we would have preferred,but experience shows that people’s ideas of what is funny differ dramatically andthat a failed attempt at humor can be confusing.

We do not pretend that our ideas or the tools offered are perfect. No tool, li-brary, language, or technique is “the solution” to all of the many challenges fac-ing a programmer. At best, it can help you to develop and express your solution.We try hard to avoid “white lies”; that is, we refrain from oversimplified explana-tions that are clear and easy to understand, but not true in the context of real lan-guages and real problems. On the other hand, this book is not a reference; formore precise and complete descriptions of C++, see Bjarne Stroustrup, The C++Programming Language, Special Edition (Addison-Wesley, 2000), and the ISO C++standard.

0.1.2 Drills, exercises, etc.Programming is not just an intellectual activity, so writing programs is necessaryto master programming skills. We provide two levels of programming practice:

• Drills: A drill is a very simple exercise devised to develop practical, al-most mechanical skills. A drill usually consists of a sequence of modifica-tions of a single program. You should do every drill. A drill is not askingfor deep understanding, cleverness, or initiative. We consider the drillspart of the basic fabric of the book. If you haven’t done the drills, youhave not “done” the book.


0.1 THE STRUCTURE OF THIS BOOK 5

• Exercises: Some exercises are trivial and others are very hard, but mostare intended to leave some scope for initiative and imagination. If youare serious, you’ll do quite a few exercises. At least do enough to knowwhich are difficult for you. Then do a few more of those. That’s howyou’ll learn the most. The exercises are meant to be manageable withoutexceptional cleverness, rather than to be tricky puzzles. However, wehope that we have provided exercises that are hard enough to challengeanybody and enough exercises to exhaust even the best student’s avail-able time. We do not expect you to do them all, but feel free to try.

In addition, we recommend that you (every student) take part in a small project(and more if time allows for it). A project is intended to produce a complete usefulprogram. Ideally, a project is done by a small group of people (e.g., three people)working together for about a month while working through the chapters in PartIII. Most people find the projects the most fun and what ties everything together.

Some people like to put the book aside and try some examples before read-ing to the end of a chapter; others prefer to read ahead to the end before trying toget code to run. To support readers with the former preference, we provide sim-ple suggestions for practical work labeled “Try this:” at natural breaks in thetext. A Try this is generally in the nature of a drill focused narrowly on the topicthat precedes it. If you pass a Try this without trying — maybe because you arenot near a computer or you find the text riveting — do return to it when you dothe chapter drill; a Try this either complements the chapter drill or is a part of it.

At the end of each chapter you’ll find a set of review questions. They are in-tended to point you to the key ideas explained in the chapter. One way to look atthe review questions is as a complement to the exercises: the exercises focus on thepractical aspects of programming, whereas the review questions try to help you ar-ticulate the ideas and concepts. In that, they resemble good interview questions.

The “Terms” section at the end of each chapter presents the basic vocabularyof programming and of C++. If you want to understand what people say aboutprogramming topics and to articulate your own ideas, you should know whateach means.

Learning involves repetition. Our ideal is to make every important point atleast twice and to reinforce it with exercises.

0.1.3 What comes after this book?At the end of this book, will you be an expert at programming and at C++? Ofcourse not! When done well, programming is a subtle, deep, and highly skilledart building on a variety of technical skills. You should no more expect to be anexpert at programming in four months than you should expect to be an expert inbiology, in math, in a natural language (such as Chinese, English, or Danish), orat playing the violin in four months — or in half a year, or a year. What you


should hope for, and what you can expect if you approach this book seriously, isto have a really good start that allows you to write relatively simple useful pro-grams, to be able to read more complex programs, and to have a good concep-tual and practical background for further work.

The best follow-up to this initial course is to work on a real project develop-ing code to be used by someone else. After that, or (even better) in parallel with areal project, read either a professional-level general textbook (such as Stroustrup,The C++ Programming Language), a more specialized book relating to the needs ofyour project (such as Qt for GUI, or ACE for distributed programming), or atextbook focusing on a particular aspect of C++ (such as Koenig and Moo, Accel-erated C++; Sutter’s Exceptional C++; or Gamma et al., Design Patterns). For com-plete references, see §0.6 or the Bibliography section at the back of the book.

Eventually, you should learn another programming language. We don’t con-sider it possible to be a professional in the realm of software — even if you are notprimarily a programmer — without knowing more than one language.

0.2 A philosophy of teaching and learningWhat are we trying to help you learn? And how are we approaching the processof teaching? We try to present the minimal concepts, techniques, and tools foryou to do effective practical programs, including

• Program organization• Debugging and testing• Class design• Computation• Function and algorithm design• Graphics (two-dimensional only)• Graphical user interfaces (GUIs)• Text manipulation• Regular expression matching• Files and stream input and output (I/O)• Memory management• Scientific/numerical/engineering calculations• Design and programming ideals• The C++ standard library• Software development strategies• C-language programming techniques

6 CHAPTER 0 • NOTES TO THE READER


Working our way through these topics, we cover the programming techniquescalled procedural programming (as with the C programming language), data ab-straction, object-oriented programming, and generic programming. The maintopic of this book is programming, that is, the ideals, techniques, and tools of ex-pressing ideas in code. The C++ programming language is our main tool, so wedescribe many of C++’s facilities in some detail. But please remember that C++is just a tool, rather than the main topic of this book. This is “programming usingC++,” not “C++ with a bit of programming theory.”

Each topic we address serves at least two purposes: it presents a technique,concept, or principle and also a practical language or library feature. For exam-ple, we use the interface to a two-dimensional graphics system to illustrate the useof classes and inheritance. This allows us to be economical with space (and yourtime) and also to emphasize that programming is more than simply slinging codetogether to get a result as quickly as possible. The C++ standard library is amajor source of such “double duty” examples — many even do triple duty. Forexample, we introduce the standard library vector, use it to illustrate widely use-ful design techniques, and show many of the programming techniques used toimplement it. One of our aims is to show you how major library facilities are im-plemented and how they map to hardware. We insist that craftsmen must under-stand their tools, not just consider them “magical.”

Some topics will be of greater interest to some programmers than to others.However, we encourage you not to prejudge your needs (how would you knowwhat you’ll need in the future?) and at least look at every chapter. If you read thisbook as part of a course, your teacher will guide your selection.

We characterize our approach as “depth-first.” It is also “concrete-first” and“concept-based.” First, we quickly (well, relatively quickly, Chapters 1–11) assem-ble a set of skills needed for writing small practical programs. In doing so, wepresent a lot of tools and techniques in minimal detail. We focus on simple con-crete code examples because people grasp the concrete faster than the abstract.That’s simply the way most humans learn. At this initial stage, you should notexpect to understand every little detail. In particular, you’ll find that trying some-thing slightly different from what just worked can have “mysterious” effects. Dotry, though! And please do the drills and exercises we provide. Just rememberthat early on you just don’t have the concepts and skills to accurately estimatewhat’s simple and what’s complicated; expect surprises and learn from them.

We move fast in this initial phase — we want to get you to the point whereyou can write interesting programs as fast as possible. Someone will argue, “Wemust move slowly and carefully; we must walk before we can run!” But have youever watched a baby learning to walk? Babies really do run by themselves beforethey learn the finer skills of slow, controlled walking. Similarly, you will dashahead, occasionally stumbling, to get a feel of programming before slowing downto gain the necessary finer control and understanding. You must run before youcan walk!

70.2 A PHILOSOPHY OF TEACHING AND LEARNING


It is essential that you don’t get stuck in an attempt to learn “everything”about some language detail or technique. For example, you could memorize all ofC++’s built-in types and all the rules for their use. Of course you could, anddoing so might make you feel knowledgeable. However, it would not make you aprogrammer. Skipping details will get you “burned” occasionally for lack ofknowledge, but it is the fastest way to gain the perspective needed to write goodprograms. Note that our approach is essentially the one used by children learningtheir native language and also the most effective approach used to teach foreignlanguages. We encourage you to seek help from teachers, friends, colleagues, in-structors, Mentors, etc. on the inevitable occasions when you are stuck. Be as-sured that nothing in these early chapters is fundamentally difficult. However,much will be unfamiliar and might therefore feel difficult at first.

Later, we build on the initial skills to broaden your base of knowledge andskills. We use examples and exercises to solidify your understanding, and to pro-vide a conceptual base for programming.

We place a heavy emphasis on ideals and reasons. You need ideals to guideyou when you look for practical solutions — to know when a solution is good andprincipled. You need to understand the reasons behind those ideals to under-stand why they should be your ideals, why aiming for them will help you and theusers of your code. Nobody should be satisfied with “because that’s the way it is”as an explanation. More importantly, an understanding of ideals and reasons al-lows you to generalize from what you know to new situations and to combineideas and tools in novel ways to address new problems. Knowing “why” is an es-sential part of acquiring programming skills. Conversely, just memorizing lots ofpoorly understood rules and language facilities is limiting, a source of errors, anda massive waste of time. We consider your time precious and try not to waste it.

Many C++ language-technical details are banished to appendices and manu-als, where you can look them up when needed. We assume that you have the ini-tiative to search out information when needed. Use the index and the table ofcontents. Don’t forget the online help facilities of your compiler, and the web. Re-member, though, to consider every web resource highly suspect until you havereason to believe better of it. Many an authoritative-looking website is put up bya programming novice or someone with something to sell. Others are simply out-dated. We provide a collection of links and information on our support website:www.stroustrup.com/Programming.

Please don’t be too impatient for “realistic” examples. Our ideal example isthe shortest and simplest code that directly illustrates a language facility, a con-cept, or a technique. Most real-world examples are far messier than ours, yet donot consist of more than a combination of what we demonstrate. Successful com-mercial programs with hundreds of thousands of lines of code are based on tech-niques that we illustrate in a dozen 50-line programs. The fastest way tounderstand real-world code is through a good understanding of the fundamentals.



On the other hand, we do not use “cute examples involving cuddly animals”to illustrate our points. We assume that you aim to write real programs to beused by real people, so every example that is not presented as language-technicalis taken from a real-world use. Our basic tone is that of professionals addressing(future) professionals.

0.2.1 The order of topicsThere are many ways to teach people how to program. Clearly, we don’t sub-scribe to the popular “the way I learned to program is the best way to learn” the-ories. To ease learning, we early on present topics that would have beenconsidered advanced only a few years ago. Our ideal is for the topics we presentto be driven by problems you meet as you learn to program, to flow smoothlyfrom topic to topic as you increase your understanding and practical skills. Themajor flow of this book is more like a story than a dictionary or a hierarchicalorder.

It is impossible to learn all the principles, techniques, and language facilitiesneeded to write a program at once. Consequently, we have to choose a subset ofprinciples, techniques, and features to start with. More generally, a textbook or acourse must lead students through a series of subsets. We consider it our respon-sibility to select topics and to provide emphasis. We can’t just present everything,so we must choose; what we leave out is at least as important as what we leave in— at each stage of the journey.

For contrast, it may be useful for you to see a list of (severely abbreviated)characterizations of approaches that we decided not to take:

• “C first”: This approach to learning C++ is wasteful of students’ timeand leads to poor programming practices by forcing students to ap-proach problems with fewer facilities, techniques, and libraries than nec-essary. C++ provides stronger type checking than C, a standard librarywith better support for novices, and exceptions for error handling.

• Bottom-up: This approach distracts from learning good and effective pro-gramming practices. By forcing students to solve problems with insuffi-cient support from the language and libraries, it promotes poor andwasteful programming practices.

• “If you present something, you must present it fully”: This approach implies abottom-up approach (by drilling deeper and deeper into every topictouched). It bores novices with technical details they have no interest inand quite likely will not need for years to come. Once you can program,you can look up technical details in a manual. Manuals are good at that,whereas they are awful for initial learning of concepts.



• Top-down: This approach, working from first principles toward details,tends to distract readers from the practical aspects of programming andforce them to concentrate on high-level concepts before they have anychance of appreciating their importance. For example, you simply can’tappreciate proper software development principles before you havelearned how easy it is to make a mistake in a program and how hard itcan be to correct it.

• “Abstract first”: Focusing on general principles and protecting the studentfrom nasty real-world constraints can lead to a disdain for real-worldproblems, languages, tools, and hardware constraints. Often, this ap-proach is supported by “teaching languages” that cannot be used laterand (deliberately) insulate students from hardware and system concerns.

• Software engineering principles first: This approach and the abstract-first ap-proach tend to share the problems of the top-down approach: withoutconcrete examples and practical experience, you simply cannot appreci-ate the value of abstraction and proper software development practices.

• “Object-oriented from day one”: Object-oriented programming is one of thebest ways of organizing code and programming efforts, but it is not theonly effective way. In particular, we feel that a grounding in the basics oftypes and algorithmic code is a prerequisite for appreciation of the designof classes and class hierarchies. We do use user-defined types (what somepeople would call “objects”) from day one, but we don’t show how to de-sign a class until Chapter 6 and don’t show a class hierarchy until Chap-ter 12.

• “Just believe in magic”: This approach relies on demonstrations of power-ful tools and techniques without introducing the novice to the underly-ing techniques and facilities. This leaves the student guessing — andusually guessing wrong — about why things are the way they are, what itcosts to use them, and where they can be reasonably applied. This canlead to overrigid following of familiar patterns of work and become abarrier to further learning.

Naturally, we do not claim that these other approaches are never useful. In fact,we use several of these for specific subtopics where their strengths can be appre-ciated. However, as general approaches to learning programming aimed at real-world use, we reject them and apply our alternative: concrete-first and depth-firstwith an emphasis on concepts and techniques.

0.2.2 Programming and programming languageWe teach programming first and treat our chosen programming language as sec-ondary, as a tool. Our general approach can be used with any general-purpose



programming language. Our primary aim is to help you learn general concepts,principles, and techniques. However, those cannot be appreciated in isolation.For example, details of syntax, the kinds of ideas that can be directly expressed,and tool support differ from programming language to programming language.However, many of the fundamental techniques for producing bug-free code, suchas writing logically simple code (Chapters 5 and 6), establishing invariants(§9.4.3), and separating interfaces from implementation details (§9.7 and§14.1–2), vary little from programming language to programming language.

Programming and design techniques must be learned using a programminglanguage. Design, code organization, and debugging are not skills you can ac-quire in the abstract. You need to write code in some programming language andgain practical experience with that. This implies that you must learn the basics ofa programming language. We say “the basics” because the days when you couldlearn all of a major industrial language in a few weeks are gone for good. Theparts of C++ we present were chosen as the subset that most directly supportsthe production of good code. Also, we present C++ features that you can’t avoidencountering either because they are necessary for logical completeness or arecommon in the C++ community.

0.2.3 PortabilityIt is common to write C++ to run on a variety of machines. Major C++ applica-tions run on machines we haven’t ever heard of! We consider portability and the useof a variety of machine architectures and operating systems most important. Essen-tially every example in this book is not only ISO Standard C++, but also portable.Unless specifically stated, the code we present should work on every C++ imple-mentation and has been tested on several machines and operating systems.

The details of how to compile, link, and run a C++ program differ from systemto system. It would be tedious to mention the details of every system and everycompiler each time we need to refer to an implementation issue. In Appendix E, wegive the most basic information about getting started using Visual Studio andMicrosoft C++ on a Windows machine.

If you have trouble with one of the popular, but rather elaborate, IDEs (inte-grated development environments), we suggest you try working from the com-mand line; it’s surprisingly simple. For example, here is the full set of commandsneeded to compile, link, and execute a simple program consisting of two sourcefiles, my_file1.cpp and my_file2.cpp, using the GNU C++ compiler, g++, on aUnix or Linux system:

g++ –o my_program my_file1.cpp my_file2.cppmy_program

Yes, that really is all it takes.



0.3 Programming and computer scienceIs programming all that there is to computer science? Of course not! The onlyreason we raise this question is that people have been known to be confusedabout this. We touch upon major topics from computer science, such as algo-rithms and data structures, but our aim is to teach programming: the design andimplementation of programs. That is both more and less than most accepted no-tions of computer science:

• More, because programming involves many technical skills that are notusually considered part of any science

• Less, because we do not systematically present the foundation for theparts of computer science we use

The aim of this book is to be part of a course in computer science (if becoming acomputer scientist is your aim), to be the foundation for the first of many coursesin software construction and maintenance (if your aim is to become a program-mer or a software engineer), and in general to be part of a greater whole.

We rely on computer science throughout and we emphasize principles, butwe teach programming as a practical skill based on theory and experience, ratherthan as a science.

0.4 Creativity and problem solvingThe primary aim of this book is to help you to express your ideas in code, not toteach you how to get those ideas. Along the way, we give many examples of howwe can address a problem, usually through analysis of a problem followed bygradual refinement of a solution. We consider programming itself a form of prob-lem solving: only through complete understanding of a problem and its solutioncan you express a correct program for it, and only through constructing and test-ing a program can you be certain that your understanding is complete. Thus,programming is inherently part of an effort to gain understanding. However, weaim to demonstrate this through examples, rather than through “preaching” orpresentation of detailed prescriptions for problem solving.

0.5 Request for feedbackWe don’t think that the perfect textbook can exist; the needs of individuals differtoo much for that. However, we’d like to make this book and its supporting ma-terials as good as we can make them. For that, we need feedback; a good text-book cannot be written in isolation from its readers. Please send us reports on



errors, typos, unclear text, missing explanations, etc. We’d also appreciate sug-gestions for better exercises, better examples, and topics to add, topics to delete,etc. Constructive comments will help future readers and we’ll post errata on oursupport website: www.stroustrup.com/Programming.

0.6 ReferencesAlong with listing the publications mentioned in this chapter, this section also in-cludes publications you might find helpful.

Austern, Matthew H. Generic Programming and the STL: Using and Extending the C++Standard Template Library. Addison-Wesley, 1999. ISBN 0201309564.

Austern, Matthew H. (editor). “Technical Report on C++ Standard Library Ex-tensions.” ISO/IEC PDTR 19768.

Blanchette, Jasmin, and Mark Summerfield. C++ GUI Programming with Qt 4.Prentice Hall, 2006. ISBN 0131872493.

Gamma, Erich, Richard Helm, Ralph Johnson, and John M. Vlissides. DesignPatterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994. ISBN0201633612.

Goldthwaite, Lois (editor). “Technical Report on C++ Performance.” ISO/IECPDTR 18015.

Koenig, Andrew (editor). The C++ Standard. ISO/IEC 14882:2002. Wiley, 2003.ISBN 0470846747.

Koenig, Andrew, and Barbara Moo. Accelerated C++: Practical Programming by Example.Addison-Wesley, 2000. ISBN 020170353X.

Langer, Angelika, and Klaus Kreft. Standard C++ IOStreams and Locales: AdvancedProgrammer’s Guide and Reference. Addison-Wesley, 2000. ISBN 0201183951.

Meyers, Scott. Effective STL: 50 Specific Ways to Improve Your Use of the Standard Tem-plate Library. Addison-Wesley, 2001. ISBN 0201749625.

Meyers, Scott. Effective C++: 55 Specific Ways to Improve Your Programs and Designs(3rd Edition). Addison-Wesley, 2005. ISBN 0321334876.

Schmidt, Douglas C., and Stephen D. Huston. C++ Network Programming, Volume1: Mastering Complexity with ACE and Patterns. Addison-Wesley, 2002. ISBN0201604647.

Schmidt, Douglas C., and Stephen D. Huston. C++ Network Programming, Volume2: Systematic Reuse with ACE and Frameworks. Addison-Wesley, 2003. ISBN0201795256.

Stroustrup, Bjarne. The Design and Evolution of C++. Addison-Wesley, 1994. ISBN0201543303.

Stroustrup, Bjarne. “Learning Standard C++ as a New Language.” C/C++ UsersJournal,May 1999.

130.6 REFERENCES


Stroustrup, Bjarne. The C++ Programming Language (Special Edition). Addison-Wesley, 2000. ISBN 0201700735.

Stroustrup, Bjarne. “C and C++: Siblings”; “C and C++: A Case for Compati-bility”; and “C and C++: Case Studies in Compatibility.” C/C++ Users Journal,July, Aug., Sept. 2002.

Sutter, Herb. Exceptional C++: 47 Engineering Puzzles, Programming Problems, and Solu-tions. Addison-Wesley, 2000. ISBN 0201615622.

A more comprehensive list of references can be found in the Bibliography sectionat the back of the book.

0.7 BiographiesYou might reasonably ask, “Who are these guys who want to teach me how toprogram?” So here is some biographical information. I, Bjarne Stroustrup, wrotethis book, and together with Lawrence “Pete” Petersen, I designed and taught theuniversity-level beginner’s (first-year) course that was developed concurrentlywith the book, using drafts of the book.

Bjarne StroustrupI’m the designer and original implementer of theC++ programming language. I have used the lan-guage, and many other programming languages,for a wide variety of programming tasks over thelast 30 years or so. I just love elegant and efficientcode used in challenging applications, such asrobot control, graphics, games, text analysis, andnetworking. I have taught design, programming,and C++ to people of essentially all abilities andinterests. I’m a founding member of the ISO stan-dards committee for C++ where I serve as the

chair of the working group for language evolution.This is my first introductory book. My other books, such as The C++ Pro-

gramming Language and The Design and Evolution of C++, were written for experi-enced programmers.

I was born into a blue-collar (working-class) family in Århus, Denmark, andgot my master’s degree in mathematics with computer science in my hometownuniversity. My Ph.D. in computer science is from Cambridge University, Eng-land. I worked for AT&T for about 25 years, first in the famous Computer Sci-ence Research Center of Bell Labs — where Unix, C, C++, and so much elsewere invented — and later in AT&T Labs–Research.

I’m a member of the U.S. National Academy of Engineering, a Fellow of theACM, an IEEE Fellow, a Bell Laboratories Fellow, and an AT&T Fellow. As the



first computer scientist ever, I received the 2005 William Procter Prize for Scien-tific Achievement from Sigma Xi (the scientific research society).

I do have a life outside work. I’m married and have two children, one a med-ical doctor and one a Ph.D. student. I read a lot (including history, science fiction,crime, and current affairs) and like most kinds of music (including classical, rock,blues, and country). Good food with friends is an essential part of life, and Ienjoy visiting interesting places and people, all over the world. To be able toenjoy the good food, I run.

For more information, see my home pages: www.research.att.com/~bs andwww.cs.tamu.edu/people/faculty/bs. In particular, there you can find out how topronounce my name.

Lawrence “Pete” PetersenIn late 2006, Pete introduced himself as follows: “Iam a teacher. For almost 20 years, I have taughtprogramming languages at Texas A&M. I havebeen selected by students for Teaching ExcellenceAwards five times and in 1996 received the Distin-guished Teaching Award from the Alumni Associ-ation for the College of Engineering. I am aFellow of the Wakonse Program for Teaching Ex-cellence and a Fellow of the Academy for Educa-tor Development.

As the son of an army officer, I was raised onthe move. After completing a degree in philosophy at the University of Washing-ton, I served in the army for 22 years as a Field Artillery Officer and as a ResearchAnalyst for Operational Testing. I taught at the Field Artillery Officer’s AdvancedCourse at Fort Sill, Oklahoma, from 1971 to 1973. In 1979 I helped organize aTest Officer’s Training Course and taught it as lead instructor at nine different lo-cations across the United States from 1978 to 1981 and from 1985 to 1989.

In 1991 I formed a small software company that produced management soft-ware for university departments until 1999. My interests are in teaching, design-ing, and programming software that real people can use. I completed master’sdegrees in industrial engineering at Georgia Tech and in education curriculumand instruction at Texas A&M. I also completed a master’s program in micro-computers from NTS. My Ph.D. is in information and operations managementfrom Texas A&M.

My wife, Barbara, and I live in Bryan, Texas. We like to travel, garden, andentertain; and we spend as much time as we can with our sons and their families,and especially with our grandchildren, Angelina, Carlos, Tess, Avery, Nicholas,and Jordan.”

Sadly, Pete died of lung cancer in 2007. Without him, the course would neverhave succeeded.

150.7 BIOGRAPHIES



PostscriptMost chapters provide a short “postscript” trying to give some perspective on theinformation presented in the chapter. We do that in the realization that the infor-mation can be — and often is — daunting and will only be fully comprehendedafter doing exercises, reading further chapters (which apply the ideas of the chap-ter), and a later review. Don’t panic. Relax; this is natural and expected. Youwon’t become an expert in a day, but you can become a reasonably competentprogrammer as you work your way through the book. On the way, you’ll en-counter much information, many examples, and many techniques that lots ofprogrammers have found stimulating and fun.


Documents

Chapter 0: Notes to the Reader - Bjarne Stroustrup's Homepage