The C++ Programming Language Third Edition Bjarne Stroustrup AT&T Labs Murray Hill, New Jersey Addison-Wesley An Imprint of Addison Wesley Longman, Inc Reading, Massachusetts • Harlow, England • Menlo Park, California Berkeley, California • Don Mills, Ontario • Sydney Bonn • Amsterdam • Tokyo • Mexico City ii Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks Where those designations appear in this book, and Addison-Wesley was aware of a trademark claim, the designations have been printed in initial capital letters or all capital letters The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information contained herein The publisher offers discounts on this book when ordered in quantity for special sales For more information please contact: Corporate & Professional Publishing Group Addison-Wesley Publishing Company One Jacob Way Reading, Massachusetts 01867 Library of Congress Cataloging-in-Publication Data Stroustrup, Bjarne The C++ Programming Language / Bjarne Stroustrup — 3rd ed p cm Includes index ISBN 0-201-88954-4 C++ (Computer Programming Language) I Title QA76.73.C153S77 1997 97-20239 005.13’3—dc21 CIP Copyright © 1997 by AT&T All rights reserved No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of the publisher Printed in the United States of America This book was typeset in Times and Courier by the author ISBN 0-201-88954-4 Printed on recycled paper 9—CRW—0100999897 First printing, June 1997 Contents Contents iii Preface v Preface to Second Edition vii Preface to First Edition ix Introductory Material 1 Notes to the Reader A Tour of C++ A Tour of the Standard Library 21 45 Part I: Basic Facilities Types and Declarations Pointers, Arrays, and Structures Expressions and Statements Functions Namespaces and Exceptions Source Files and Programs 67 69 87 107 143 165 197 The C++ Programming Language, Third Edition by Bjarne Stroustrup Copyright ©1997 by AT&T Published by Addison Wesley Longman, Inc ISBN 0-201-88954-4 All rights reserved iv Contents Part II: Abstraction Mechanisms 10 11 12 13 14 15 Classes Operator Overloading Derived Classes Templates Exception Handling Class Hierarchies Part III: The Standard Library 16 17 18 19 20 21 22 Library Organization and Containers Standard Containers Algorithms and Function Objects Iterators and Allocators Strings Streams Numerics Part IV: Design Using C++ 23 Development and Design 24 Design and Programming 25 Roles of Classes Appendices A The C++ Grammar B Compatibility C Technicalities Index 221 223 261 301 327 355 389 427 429 461 507 549 579 605 657 689 691 723 765 791 793 815 827 869 The C++ Programming Language, Third Edition by Bjarne Stroustrup Copyright ©1997 by AT&T Published by Addison Wesley Longman, Inc ISBN 0-201-88954-4 All rights reserved Preface to the First Edition Language shapes the way we think, and determines what we can think about – B.L.Whorf C++ is a general purpose programming language designed to make programming more enjoyable for the serious programmer Except for minor details, C++ is a superset of the C programming language In addition to the facilities provided by C, C++ provides flexible and efficient facilities for defining new types A programmer can partition an application into manageable pieces by defining new types that closely match the concepts of the application This technique for program construction is often called data abstraction Objects of some user-defined types contain type information Such objects can be used conveniently and safely in contexts in which their type cannot be determined at compile time Programs using objects of such types are often called object based When used well, these techniques result in shorter, easier to understand, and easier to maintain programs The key concept in C++ is class A class is a user-defined type Classes provide data hiding, guaranteed initialization of data, implicit type conversion for user-defined types, dynamic typing, user-controlled memory management, and mechanisms for overloading operators C++ provides much better facilities for type checking and for expressing modularity than C does It also contains improvements that are not directly related to classes, including symbolic constants, inline substitution of functions, default function arguments, overloaded function names, free store management operators, and a reference type C++ retains C’s ability to deal efficiently with the fundamental objects of the hardware (bits, bytes, words, addresses, etc.) This allows the user-defined types to be implemented with a pleasing degree of efficiency C++ and its standard libraries are designed for portability The current implementation will run on most systems that support C C libraries can be used from a C++ program, and most tools that support programming in C can be used with C++ This book is primarily intended to help serious programmers learn the language and use it for nontrivial projects It provides a complete description of C++, many complete examples, and many more program fragments The C++ Programming Language, Third Edition by Bjarne Stroustrup Copyright ©1997 by AT&T Published by Addison Wesley Longman, Inc ISBN 0-201-88954-4 All rights reserved x Preface to the First Edition Acknowledgments C++ could never have matured without the constant use, suggestions, and constructive criticism of many friends and colleagues In particular, Tom Cargill, Jim Coplien, Stu Feldman, Sandy Fraser, Steve Johnson, Brian Kernighan, Bart Locanthi, Doug McIlroy, Dennis Ritchie, Larry Rosler, Jerry Schwarz, and Jon Shopiro provided important ideas for development of the language Dave Presotto wrote the current implementation of the stream I/O library In addition, hundreds of people contributed to the development of C++ and its compiler by sending me suggestions for improvements, descriptions of problems they had encountered, and compiler errors I can mention only a few: Gary Bishop, Andrew Hume, Tom Karzes, Victor Milenkovic, Rob Murray, Leonie Rose, Brian Schmult, and Gary Walker Many people have also helped with the production of this book, in particular, Jon Bentley, Laura Eaves, Brian Kernighan, Ted Kowalski, Steve Mahaney, Jon Shopiro, and the participants in the C++ course held at Bell Labs, Columbus, Ohio, June 26-27, 1985 Murray Hill, New Jersey Bjarne Stroustrup The C++ Programming Language, Third Edition by Bjarne Stroustrup Copyright ©1997 by AT&T Published by Addison Wesley Longman, Inc ISBN 0-201-88954-4 All rights reserved Preface to the Second Edition The road goes ever on and on – Bilbo Baggins As promised in the first edition of this book, C++ has been evolving to meet the needs of its users This evolution has been guided by the experience of users of widely varying backgrounds working in a great range of application areas The C++ user-community has grown a hundredfold during the six years since the first edition of this book; many lessons have been learned, and many techniques have been discovered and/or validated by experience Some of these experiences are reflected here The primary aim of the language extensions made in the last six years has been to enhance C++ as a language for data abstraction and object-oriented programming in general and to enhance it as a tool for writing high-quality libraries of user-defined types in particular A ‘‘high-quality library,’’ is a library that provides a concept to a user in the form of one or more classes that are convenient, safe, and efficient to use In this context, safe means that a class provides a specific type-safe interface between the users of the library and its providers; efficient means that use of the class does not impose significant overheads in run-time or space on the user compared with handwritten C code This book presents the complete C++ language Chapters through 10 give a tutorial introduction; Chapters 11 through 13 provide a discussion of design and software development issues; and, finally, the complete C++ reference manual is included Naturally, the features added and resolutions made since the original edition are integral parts of the presentation They include refined overloading resolution, memory management facilities, and access control mechanisms, type-safe linkage, c on st and s ta ti c member functions, abstract classes, multiple inheritance, templates, and co ns t st at ic exception handling C++ is a general-purpose programming language; its core application domain is systems programming in the broadest sense In addition, C++ is successfully used in many application areas that are not covered by this label Implementations of C++ exist from some of the most modest microcomputers to the largest supercomputers and for almost all operating systems Consequently, this book describes the C++ language itself without trying to explain a particular implementation, programming environment, or library This book presents many examples of classes that, though useful, should be classified as ‘‘toys.’’ This style of exposition allows general principles and useful techniques to stand out more The C++ Programming Language, Third Edition by Bjarne Stroustrup Copyright ©1997 by AT&T Published by Addison Wesley Longman, Inc ISBN 0-201-88954-4 All rights reserved viii Preface to the Second Edition clearly than they would in a fully elaborated program, where they would be buried in details Most of the useful classes presented here, such as linked lists, arrays, character strings, matrices, graphics classes, associative arrays, etc., are available in ‘‘bulletproof’’ and/or ‘‘goldplated’’ versions from a wide variety of commercial and non-commercial sources Many of these ‘‘industrial strength’’ classes and libraries are actually direct and indirect descendants of the toy versions found here This edition provides a greater emphasis on tutorial aspects than did the first edition of this book However, the presentation is still aimed squarely at experienced programmers and endeavors not to insult their intelligence or experience The discussion of design issues has been greatly expanded to reflect the demand for information beyond the description of language features and their immediate use Technical detail and precision have also been increased The reference manual, in particular, represents many years of work in this direction The intent has been to provide a book with a depth sufficient to make more than one reading rewarding to most programmers In other words, this book presents the C++ language, its fundamental principles, and the key techniques needed to apply it Enjoy! Acknowledgments In addition to the people mentioned in the acknowledgements section in the preface to the first edition, I would like to thank Al Aho, Steve Buroff, Jim Coplien, Ted Goldstein, Tony Hansen, Lorraine Juhl, Peter Juhl, Brian Kernighan, Andrew Koenig, Bill Leggett, Warren Montgomery, Mike Mowbray, Rob Murray, Jonathan Shopiro, Mike Vilot, and Peter Weinberger for commenting on draft chapters of this second edition Many people influenced the development of C++ from 1985 to 1991 I can mention only a few: Andrew Koenig, Brian Kernighan, Doug McIlroy, and Jonathan Shopiro Also thanks to the many participants of the ‘‘external reviews’’ of the reference manual drafts and to the people who suffered through the first year of X3J16 Murray Hill, New Jersey Bjarne Stroustrup The C++ Programming Language, Third Edition by Bjarne Stroustrup Copyright ©1997 by AT&T Published by Addison Wesley Longman, Inc ISBN 0-201-88954-4 All rights reserved Preface Programming is understanding – Kristen Nygaard I find using C++ more enjoyable than ever C++’s support for design and programming has improved dramatically over the years, and lots of new helpful techniques have been developed for its use However, C++ is not just fun Ordinary practical programmers have achieved significant improvements in productivity, maintainability, flexibility, and quality in projects of just about any kind and scale By now, C++ has fulfilled most of the hopes I originally had for it, and also succeeded at tasks I hadn’t even dreamt of This book introduces standard C++† and the key programming and design techniques supported by C++ Standard C++ is a far more powerful and polished language than the version of C++ introduced by the first edition of this book New language features such as namespaces, exceptions, templates, and run-time type identification allow many techniques to be applied more directly than was possible before, and the standard library allows the programmer to start from a much higher level than the bare language About a third of the information in the second edition of this book came from the first This third edition is the result of a rewrite of even larger magnitude It offers something to even the most experienced C++ programmer; at the same time, this book is easier for the novice to approach than its predecessors were The explosion of C++ use and the massive amount of experience accumulated as a result makes this possible The definition of an extensive standard library makes a difference to the way C++ concepts can be presented As before, this book presents C++ independently of any particular implementation, and as before, the tutorial chapters present language constructs and concepts in a ‘‘bottom up’’ order so that a construct is used only after it has been defined However, it is much easier to use a well-designed library than it is to understand the details of its implementation Therefore, the standard library can be used to provide realistic and interesting examples well before a reader can be assumed to understand its inner workings The standard library itself is also a fertile source of programming examples and design techniques † ISO/IEC 14882, Standard for the C++ Programming Language The C++ Programming Language, Third Edition by Bjarne Stroustrup Copyright ©1997 by AT&T Published by Addison Wesley Longman, Inc ISBN 0-201-88954-4 All rights reserved - 12 - complex a = 2; complex b = a+2; b = 2+a; // interpreted as operator+(a,complex(2)) // interpreted as operator+(complex(2),a) Only one function is needed to interpret ‘‘+’’ operations and the two operands are handled identically by the type system Furthermore, class complex is written without any need to modify the concept of integers to enable the smooth and natural integration of the two concepts This is in contrast to a ‘‘pure objectoriented system’’ where the operations would be interpreted like this: a+2; 2+a; // a.operator+(2) // 2.operator+(a) making it necessary to modify class integer to make 2+a legal Modifying existing code should be avoided as far as possible when adding new facilities to a system Typically, object-oriented programming offers superior facilities for adding to a system without modifying existing code In this case, however, data abstraction facilities provide a better solution Iterators It has been claimed that a language supporting data abstraction must provide a way of defining control structures12 In particular, a mechanism that allows a user to define a loop over the elements of some type containing elements is often needed This must be achieved without forcing a user to depend on details of the implementation of the user-defined type Given a sufficiently powerful mechanism for defining new types and the ability to overload operators, this can be handled without a separate mechanism for defining control structures For a vector, defining an iterator is not necessary since an ordering is available to a user through the indices I’ll define one anyway to demonstrate the technique There are several possible styles of iterators My favorite relies on overloading the function application operator ()†: class vector_iterator { vector& v; int i; public: vector_iterator(vector& r) { i = 0; v = r; } int operator()() { return itakeoff(); // fine: a Saab37B is a plane cs.pop()->takeoff(); // Oops! Run time error: a Saab 900 is a car // a car does not have a takeoff method An attempt to use a car as a plane will be detected by the message handler and an appropriate error handler will be called However, that is only a consolation when the user is also the programmer The absence of static type checking makes it difficult to guarantee that errors of this class are not present in systems delivered to end-users Combinations of parameterized classes and the use of virtual functions can approach the flexibility, ease of design, and ease of use of libraries designed with method lookup without relaxing the static type checking or incurring significant run time overheads (in time or space) For example: stack cs; cs.push(new Saab900); // Compile time error: // type mismatch: car* passed, plane* expected cs.push(new Saab37B); cs.pop()->takeoff(); cs.pop()->takeoff(); // fine: a Saab 37B is a plane The use of static type checking and virtual function calls leads to a somewhat different style of programming than does dynamic type checking and method invocation For example, a Simula or C++ class specifies a fixed interface to a set of objects (of any derived class) whereas a Smalltalk class specifies an initial set of operations for objects (of any subclass) In other words, a Smalltalk class is a minimal specification and the user is free to try operations not specified whereas a C++ class is an exact specification and the user is guaranteed that only operations specified in the class declaration will be accepted by the compiler Inheritance Consider a language having some form of method lookup without having an inheritance mechanism Could that language be said to support object-oriented programming? I think not Clearly, you could interesting things with the method table to adapt the objects’ behavior to suit conditions However, to avoid chaos, there must be some systematic way of associating methods and the data structures they assume for their object representation To enable a user of an object to know what kind of behavior to expect, there would also have to be some standard way of expressing what is common to the different behaviors the object might adopt This ‘‘systematic and standard way’’ would be an inheritance mechanism Consider a language having an inheritance mechanism without virtual functions or methods Could that language be said to support object-oriented programming? I think not: the shape example does not have a good solution in such a language However, such a language would be noticeably more powerful than a ‘‘plain’’ data abstraction language This contention is supported by the observation that many Simula and C++ programs are structured using class hierarchies without virtual functions The ability to express commonality (factoring) is an extremely powerful tool For example, the problems associated with the need to have a common representation of all shapes could be solved No union would be needed However, in the absence of virtual functions, the programmer would have to resort to the use of ‘‘type fields’’ to determine actual types of objects, so the problems with the lack of modularity of the code would remain† This implies that class derivation (subclassing) is an important programming tool in its own right It † This is the problem with Simula’s inspect statement and the reason it does not have a counterpart in C++ - 17 - can be used to support object-oriented programming, but it has wider uses This is particularly true if one identifies the use of inheritance in object-oriented programming with the idea that a base class expresses a general concept of which all derived classes are specializations This idea captures only part of the expressive power of inheritance, but it is strongly encouraged by languages where every member function is virtual (or a method) Given suitable controls of what is inherited (see Snyder18 and Stroustrup19), class derivation can be a powerful tool for creating new types Given a class, derivation can be used to add and/or subtract features The relation of the resulting class to its base cannot always be completely described in terms of specialization; factoring may be a better term Derivation is another tool in the hands of a programmer and there is no foolproof way of predicting how it is going to be used – and it is too early (even after almost 25 years of Simula) to tell which uses are simply mis-uses Multiple Inheritance When a class A is a base of class B, a B inherits the attributes of an A; that is, a B is an A in addition to whatever else it might be Given this explanation it seems obvious that it might be useful to have a class B inherit from two base classes A1 and A2 This is called multiple inheritance23 A fairly standard example of the use of multiple inheritance would be to provide two library classes displayed and task for representing objects under the control of a display manager and co-routines under the control of a scheduler, respectively A programmer could then create classes such as class my_displayed_task : public displayed, public task { // my stuff }; class my_task : public task { // my stuff }; // not displayed class my_displayed : public displayed { // my stuff }; // not a task Using (only) single inheritance only two of these three choices would be open to the programmer This leads to either code replication or loss of flexibility – and typically both In C++ this example can be handled as shown above with to no significant overheads (in time or space) compared to single inheritance and without sacrificing static type checking20 Ambiguities are handled at compile time: class A { public: void f(); /* */ }; class B { public: void f(); /* */ }; class C : public A, public B { /* */ }; void g(C* p) { p->f(); // error: ambiguous } In this, C++ differs from the object-oriented Lisp dialects that support multiple inheritance In these Lisp dialects ambiguities are resolved by considering the order of declarations significant, by considering objects of the same name in different base classes identical, or by combining methods of the same name in base classes into a more complex method of the highest class In C++, one would typically resolve the ambiguity by adding a function: - 18 - class C : public A, public B { // public: void f(); // }; void f() { // C’s own stuff A::f(); B::f(); } In addition to this straightforward concept of independent multiple inheritance there appears to be a need for a more general mechanism for expressing dependencies between classes in a multiple inheritance lattice In C++, the requirement that a sub-object should be shared by all other sub-objects in a class object is expressed through the mechanism of a virtual base class: class W { /* */ }; // window class Bwindow: public virtual W { // window with border // }; class Mwindow : public virtual W { // window with menu // }; class BMW : public Bwindow, public Mwindow { // window with border and menu // }; Here the (single) window sub-object is shared by the Bwindow and Bwindow sub-objects of a BMW The Lisp dialects provide concepts of method combination to ease programming using such complicated class hierarchies C++ does not Encapsulation Consider a class member (either a data member or a function member) that needs to be protected from ‘‘unauthorized access.’’ What choices can be reasonable for delimiting the set of functions that may access that member? The ‘‘obvious’’ answer for a language supporting object-oriented programming is ‘‘all operations defined for this object,’’ that is, all member functions A non-obvious implication of this answer is that there cannot be a complete and final list of all functions that may access the protected member since one can always add another by deriving a new class from the protected member’s class and define a member function of that derived class This approach combines a large degree of protection from accident (since you not easily define a new derived class ‘‘by accident’’) with the flexibility needed for ‘‘tool building’’ using class hierarchies (since you can ‘‘grant yourself access’’ to protected members by deriving a class) For example: class Window { // protected: Rectangle inside; // public: // }; - 19 - class Dumb_terminal : Window { // public: void prompt(); // }; Here Window specifies inside as protected so that derived classes such as Dumb_terminal can read it and figure out what part of the Window’s area it may manipulate Unfortunately, the ‘‘obvious’’ answer for a language oriented towards data abstraction is different: ‘‘list the functions that need access in the class declaration.’’ There is nothing special about these functions In particular, they need not be member functions A non-member function with access to private class members is called a friend in C++ Class complex above was defined using friend functions It is sometimes important that a function may be specified as a friend in more than one class Having the full list of members and friends available is a great advantage when you are trying to understand the behavior of a type and especially when you want to modify it Encapsulation issues increase dramatically in importance with the size of the program and with the number and geographical dispersion of its users See Snyder18 and Stroustrup19 for more detailed discussions of language support for encapsulation Implementation Issues The support needed for object-oriented programming is primarily provided by the run-time system and by the programming environment Part of the reason is that object-oriented programming builds on the language improvements already pushed to their limit to support for data abstraction so that relatively few additions are needed† The use of object-oriented programming blurs the distinction between a programming language and its environment further Since more powerful special- and general-purpose user-defined types can be defined their use pervades user programs This requires further development of both the run-time system, library facilities, debuggers, performance measuring, monitoring tools, etc Ideally these are integrated into a unified programming environment Smalltalk is the best example of this Limits to Perfection A major problem with a language defined to exploit the techniques of data hiding, data abstraction, and object-oriented programming is that to claim to be a general purpose programming language it must [1] Run on traditional machines [2] Coexist with traditional operating systems [3] Compete with traditional programming languages in terms of run time efficiency [4] Cope with every major application area This implies that facilities must be available for effective numerical work (floating point arithmetic without overheads that would make Fortran appear attractive), and that facilities must be available for access to memory in a way that allows device drivers to be written It must also be possible to write calls that conform to the often rather strange standards required for traditional operating system interfaces In addition, it should be possible to call functions written in other languages from a object-oriented programming language and for functions written in the object-oriented programming language to be called from a program written in another language Another implication is that an object-oriented programming language cannot completely rely on mechanisms that cannot be efficiently implemented on a traditional architecture and still expect to be used as a general purpose language A very general implementation of method invocation can be a liability unless there are alternative ways of requesting a service Similarly, garbage collection can become a performance and portability bottleneck Most object † This assumes that an object-oriented language does indeed support data abstraction However, the support for data abstraction is often deficient in such languages Conversely, languages that support data abstraction are typically deficient in their support of objectoriented programming - 20 - oriented programming languages employ garbage collection to simplify the task of the programmer and to reduce the complexity of the language and its compiler However, it ought to be possible to use garbage collection in non-critical areas while retaining control of storage use in areas where it matters As an alternative, it is feasible to have a language without garbage collection and then provide sufficient expressive power to enable the design of types that maintain their own storage C++ is an example of this Exception handling and concurrency features are other potential problem areas Any feature that is best implemented with help from a linker can become a portability problem The alternative to having ‘‘low level’’ features in a language is to handle major application areas using separate ‘‘low level’’ languages Conclusions Object-oriented programming is programming using inheritance Data abstraction is programming using user-defined types With few exceptions, object-oriented programming can and ought to be a superset of data abstraction These techniques need proper support to be effective Data abstraction primarily needs support in the form of language features and object-oriented programming needs further support from a programming environment To be general purpose, a language supporting data abstraction or objectoriented programming must enable effective use of traditional hardware Acknowledgements An earlier version of this paper was presented to the Association of Simula Users meeting in Stockholm The discussions there caused many improvements both in style and contents Brian Kernighan and Ravi Sethi made many constructive comments Also thanks to all who helped shape C++ References [1] Birtwistle, Graham et.al.: SIMULA BEGIN Studentlitteratur, Lund, Sweden 1971 ChartwellBratt Ltd, UK 1980 [2] Dahl, O-J and Hoare, C.A.R.: Hierarchical Program Structures In Structured Programming Academic Press 1972 [3] Cargill, Tom A.: PI: A Case Study in Object-Oriented Programming SIGPLAN Notices, November 1986, pp 350-360 [4] C.C.I.T.T Study Group XI: CHILL User’s Manual CHILL Bulletin no vol March 1984 [5] Ellis, M.A and Stroustrup, B The Annotated C++ Reference Manual Addison-Wesley 1990 [6] Goldberg, A and Robson, D.: Smalltalk-80: The Language and its Implementation AddisonWesley 1983 [7] Ichbiah, J.D et.al.: Rationale for the Design of the Ada Programming Language SIGPLAN Notices, June 1979 [8] Kernighan, B.W and Ritchie, D.M.: The C Programming Language Prentice-Hall 1978 2nd Edition 1988 [9] Keene, Sonya E.: Object-Oriented Programming in COMMON LISP Addison-Wesley 1988 [10] Kerr, Ron: Object-Based Programming: A Foundation for Reliable Software Proceedings of the 14th SIMULA Users’ Conference August 1986, pp 159-165 An abbreviated version of this paper can be found under the title A Materialistic View of the Software ‘‘Engineering’’ Analogy in SIGPLAN Notices, March 1987, pp 123-125 - 21 - [11] Liskov, Barbara et al.: Clu Reference Manual MIT/LCS/TR-225, October 1979 [12] Liskov, Barbara et al.: Abstraction Mechanisms in Clu CACM vol 20, no 8, August 1977, pp 564-576 [13] Milner, Robert: A Proposal for Standard ML ACM Symposium on Lisp and Functional Programming 1984, pp 184-197 [14] Nygaard, Kristen: Basic Concepts in Object Oriented Programming SIGPLAN Notices, October 1986, pp 128-132 [15] Rovner, Paul: Extending Modula-2 to Build Large, Integrated Systems IEEE Software, Vol No November 1986, pp 46-57 [16] Shopiro, Jonathan: Extending the C++ Task System for Real-Time Applications Proc USENIX C++ Workshop, Santa Fe, November 1987 [17] SIMULA Standards Group, 1984: SIMULA Standard ASU Secretariat, Simula a.s Post Box 150 Refstad, 0513 Oslo 5, Norway [18] Snyder, Alan: Encapsulation and Inheritance in Object-Oriented Programming Languages SIGPLAN Notices, November 1986, pp 38-45 [19] Stroustrup, Bjarne: The C++ Programming Language Addison-Wesley, 1986 2nd Edition 1991 [20] Stroustrup, Bjarne: Multiple Inheritance for C++ Proceedings of the Spring’87 EUUG Conference Helsinki, May 1987 [21] Stroustrup, Bjarne: The Evolution of C++: 1985-1989 USENIX Computer Systems, Vol No 3, Summer 1989 [22] Stroustrup, Bjarne: Possible Directions for C++: 1985-1987 Proc USENIX C++ Workshop, Santa Fe, November 1987 [23] Weinreb, D and Moon, D.: Lisp Machine Manual Symbolics, Inc 1981 [24] Wirth, Niklaus: Programming in Modula-2 Springer-Verlag, 1982 [25] Woodward, P.M and Bond, S.G.: Algol 68-R Users Guide Her Majesty’s Stationery Office, London 1974 Stroustrup: The C++ Programming Language (Third Edition) homepage | C++ links | FAQ | technical FAQ | glossary | compilers | publications | TC++PL | D&E | bio | interviews | applications | TAMU CS | AT&T Research The C++ Programming Language (Third Edition and Special Edition) Addison-Wesley, ISBN 0-201-88954-4 and 0-201-70073-5 http://www.research.att.com/~bs/3rd.html (1 / 5) [2002-12-30 ｿﾀﾈﾄ 9:41:46] Stroustrup: The C++ Programming Language (Third Edition) The "special edition" is the hardcover version of the 3rd edition It differs from the early printings of the 3rd edition by about 1,000 corrections and clarifications, by two new appendices (just over 100 pages; also available online, see below), and by an improved index The only difference between the current printings of the special edition and the 3rd edition is the cover (and the price difference implied by that stronger cover) See also my FAQ Advice of the day (from TC++PL) E.7[11] Make sure that an object can always be put into a valid state without fear of an exception being thrown; secE.3.2, secE.6 Translation of the day http://www.research.att.com/~bs/3rd.html (2 / 5) [2002-12-30 ｿﾀﾈﾄ 9:41:46] Stroustrup: The C++ Programming Language (Third Edition) Chinese: ISBN 957-2054-43-0 Here is q q q q q q q q q q q the preface the preface to the second edition the preface to the first edition the Table of Contents (and an Expanded Table of Contents that is not part of the printed book) the introductory chapters r Notes to the Reader incl a discussion of the philosophy behind C++ and a brief history of C++ r A Tour of C++ presenting the basic programming techniques supported by C++ and the language features through wich C++ supports them r A Tour of the Standard Library presenting a few basic uses of C++ introducing its standard library; for most people this chapter gives a better view of C++ than does "A Tour of C++" and Appendix B: Compatibility discussing compatibility with C and earlier versions of C++ Appendix D: Locales presenting C++'s facilities for internationalization Appendix E: Standard-Library Exception Safety introducing the fundamental concepts of exception safety and presenting techniques for using exceptions well illustrated by the guarantees offered by the standard library some errata a few simple code examples a C++ glossary with references to sections of TC++PL See also a note about the structure, contents, and aims of this book For solutions to selected exercises see David Vandevoorde: C++ Solutions Addison-Wesley Longman http://www.research.att.com/~bs/3rd.html (3 / 5) [2002-12-30 ｿﾀﾈﾄ 9:41:46] Stroustrup: The C++ Programming Language (Third Edition) ISBN 0-201-30965-3 Reviews and code can be found at David's site Some of my interviews answer questions about my books For translations, see my publication list and my cover gallery Back Cover text: More than 500,000 programmers have benefited from previous editions This is a complete rewrite of the most trusted book on C++ Based on the ANSI/ISO C++ standard, this book covers the C++ language, its standard library, and key design techniques as an integrated whole The C++ Programming Language provides comprehensive coverage of C++ language features and standard library components For example: q q q q q q q q q abstract classes as interfaces class hierarchies for object-oriented programming templates as the basis for type safe generic software exceptions for regular error handling namespaces for modularity in large-scale software run-time type identification for loosely-coupled systems the C subset of C++ for C compatibility and systems-level work standard containers and algorithms standard strings, I/O streams, and numerics With this third edition Stroustrup makes C++ even more accessible to those new to the language while adding information and techniques that even expert C++ programmers find invaluable A web page to support the book can be found at http://www.aw.com/cseng/titles/0-201-88954-4 Bjarne Stroustrup is the designer and original implementor of C++ and the author of The C++ Programming Language ( first edition 1985, second edition 1991 ), The Annotated C++ Reference Manual, and The Design and Evolution of C++ A graduate of the University of Aarhus, Denmark, and Cambridge University, England, Dr Stroustrup is currently the head of AT&T Labs' Large-scale Programming Research Department and an AT&T Bell Laboratories Fellow His research interests include distributed systems, operating systems, simulation, and programming http://www.research.att.com/~bs/3rd.html (4 / 5) [2002-12-30 ｿﾀﾈﾄ 9:41:46] toto Stroustrup: The C++ Programming Language (Third Edition) Reviews: Peter Salus in ;login: October 1997: Unlike those annoying volumes whose pages are filled with screendumps, this is full of real information Bjarne has done a splendid job in this total rewrite of his important work Mini review by Francis Glassborow (Editor of C Vu (Journal of the Association of C and C++ users), September 1997: Do not be deceived, this is a new book reusing an old title It took three years to write and was critiqued by 12 technical reviewers and the author took every one of their comments seriously That is what it takes to write a good programming book (and even so some errors got missed) I will go out on a limb and declare that if you have not read this book at least once during the next twelve months you are not a C++ programmer whatever you may think As always, you will only get full benefit from your reading by thinking about what you read q q q q Angelika Langer and Klaus Kreft for DevX May 2000 Francis Glassborow for ACCU in May 2000 Al Stevens in Dr Dobb's Journal The German-language Monitor magazine If you see other reviews, please send me copies, URLs, etc homepage | C++ links | FAQ | technical FAQ | glossary | compilers | publications | TC++PL | D&E | bio | interviews | applications | TAMU CS | AT&T Research http://www.research.att.com/~bs/3rd.html (5 / 5) [2002-12-30 ｿﾀﾈﾄ 9:41:46] ... workings The standard library itself is also a fertile source of programming examples and design techniques † ISO/IEC 14882, Standard for the C++ Programming Language The C++ Programming Language, ... and their use In addition, the introductory chapters present some background information about C++, the design of C++, and the use of C++ Chapters Notes to the Reader A Tour of C++ A Tour of the. .. [notes.implementation] The language used in this book is ‘‘pure C++? ??’ as defined in the C++ standard [C++, 1997] Therefore, the examples ought to run on every C++ implementation The major program fragments