More EffectiveC++/Appendix

1.1. Books

1. Recommended Reading ¶

So your appetite for information on C++ remains unsated. Fear not, there's more — much more. In the sections that follow, I put forth my recommendations for further reading on C++. It goes without saying that such recommendations are both subjective and selective, but in view of the litigious age in which we live, it's probably a good idea to say it anyway. ¤ MEC++ Rec Reading, P2

[edit]

1.1. Books ¶

There are hundreds — possibly thousands — of books on C++, and new contenders join the fray with great frequency. I haven't seen all these books, much less read them, but my experience has been that while some books are very good, some of them, well, some of them aren't. ¤ MEC++ Rec Reading, P4

What follows is the list of books I find myself consulting when I have questions about software development in C++. Other good books are available, I'm sure, but these are the ones I use, the ones I can truly recommend. ¤ MEC++ Rec Reading, P5

A good place to begin is with the books that describe the language itself. Unless you are crucially dependent on the nuances of the °official standards documents, I suggest you do, too. ¤ MEC++ Rec Reading, P6

The Annotated C++ Reference Manual, Margaret A. Ellis and Bjarne Stroustrup, Addison-Wesley, 1990, ISBN 0-201-51459-1. ¤ MEC++ Rec Reading, P7
The Design and Evolution of C++, Bjarne Stroustrup, Addison-Wesley, 1994, ISBN 0-201-54330-3. ¤ MEC++ Rec Reading, P8

These books contain not just a description of what's in the language, they also explain the rationale behind the design decisions — something you won't find in the official standard documents. The Annotated C++ Reference Manual is now incomplete (several language features have been added since it was published — see Item 35) and is in some cases out of date, but it is still the best reference for the core parts of the language, including templates and exceptions. The Design and Evolution of C++ covers most of what's missing in The Annotated C++ Reference Manual; the only thing it lacks is a discussion of the Standard Template Library (again, see Item 35). These books are not tutorials, they're references, but you can't truly understand C++ unless you understand the material in these books

For a more general reference on the language, the standard library, and how to apply it, there is no better place to look than the book by the man responsible for C++ in the first place: ¤ MEC++ Rec Reading, P10

The C++ Programming Language (Third Edition), Bjarne Stroustrup, Addison-Wesley, 1997, ISBN 0-201-88954-4. ¤ MEC++ Rec Reading, P11

Stroustrup has been intimately involved in the language's design, implementation, application, and standardization since its inception, and he probably knows more about it than anybody else does. His descriptions of language features make for dense reading, but that's primarily because they contain so much information. The chapters on the standard C++ library provide a good introduction to this crucial aspect of modern C++. ¤ MEC++ Rec Reading, P12

If you're ready to move beyond the language itself and are interested in how to apply it effectively, you might consider my other book on the subject: ¤ MEC++ Rec Reading, P13

Effective C++, Second Edition: 50 Specific Ways to Improve Your Programs and Designs, Scott Meyers, Addison-Wesley, 1998, ISBN 0-201-92488-9. ¤ MEC++ Rec Reading, P14

That book is organized similarly to this one, but it covers different (arguably more fundamental) material. ¤ MEC++ Rec Reading, P15

A book pitched at roughly the same level as my Effective C++ books, but covering different topics, is ¤ MEC++ Rec Reading, P16

C++ Strategies and Tactics, Robert Murray, Addison-Wesley, 1993, ISBN 0-201-56382-7. ¤ MEC++ Rec Reading, P17

Murray's book is especially strong on the fundamentals of template design, a topic to which he devotes two chapters. He also includes a chapter on the important topic of migrating from C development to C++ development. Much of my discussion on reference counting (see Item 29) is based on the ideas in C++ Strategies and Tactics.

If you're the kind of person who likes to learn proper programming technique by reading code, the book for you is ¤ MEC++ Rec Reading, P19

C++ Programming Style, Tom Cargill, Addison-Wesley, 1992, ISBN 0-201-56365-7. ¤ MEC++ Rec Reading, P20

Each chapter in this book starts with some C++ software that has been published as an example of how to do something correctly. Cargill then proceeds to dissect — nay, vivisect — each program, identifying likely trouble spots, poor design choices, brittle implementation decisions, and things that are just plain wrong. He then iteratively rewrites each example to eliminate the weaknesses, and by the time he's done, he's produced code that is more robust, more maintainable, more efficient, and more portable, and it still fulfills the original problem specification. Anybody programming in C++ would do well to heed the lessons of this book, but it is especially important for those involved in code inspections. ¤ MEC++ Rec Reading, P21

One topic Cargill does not discuss in C++ Programming Style is exceptions. He turns his critical eye to this language feature in the following article, however, which demonstrates why writing exception-safe code is more difficult than most programmers realize: ¤ MEC++ Rec Reading, P22

"Exception Handling: A False Sense of Security," °C++ Report, Volume 6, Number 9, November-December 1994, pages 21-24. ¤ MEC++ Rec Reading, P23
If you are contemplating the use of exceptions, read this article before you proceed. ¤ MEC++ Rec Reading, P24

Once you've mastered the basics of C++ and are ready to start pushing the envelope, you must familiarize yourself with ¤ MEC++ Rec Reading, P25

Advanced C++: Programming Styles and Idioms, James Coplien, Addison-Wesley, 1992, ISBN 0-201-54855-0. ¤ MEC++ Rec Reading, P26

I generally refer to this as "the LSD book," because it's purple and it will expand your mind. Coplien covers some straightforward material, but his focus is really on showing you how to do things in C++ you're not supposed to be able to do. You want to construct objects on top of one another? He shows you how. You want to bypass strong typing? He gives you a way. You want to add data and functions to classes as your programs are running? He explains how to do it. Most of the time, you'll want to steer clear of the techniques he describes, but sometimes they provide just the solution you need for a tricky problem you're facing. Furthermore, it's illuminating just to see what kinds of things can be done with C++. This book may frighten you, it may dazzle you, but when you've read it, you'll never look at C++ the same way again. ¤ MEC++ Rec Reading, P27

If you have anything to do with the design and implementation of C++ libraries, you would be foolhardy to overlook ¤ MEC++ Rec Reading, P28

Designing and Coding Reusable C++, Martin D. Carroll and Margaret A. Ellis, Addison-Wesley, 1995, ISBN 0-201-51284-X. ¤ MEC++ Rec Reading, P29

Carroll and Ellis discuss many practical aspects of library design and implementation that are simply ignored by everybody else. Good libraries are small, fast, extensible, easily upgraded, graceful during template instantiation, powerful, and robust. It is not possible to optimize for each of these attributes, so one must make trade-offs that improve some aspects of a library at the expense of others. Designing and Coding Reusable C++ examines these trade-offs and offers down-to-earth advice on how to go about making them. ¤ MEC++ Rec Reading, P30

Regardless of whether you write software for scientific and engineering applications, you owe yourself a look at ¤ MEC++ Rec Reading, P31

Scientific and Engineering C++, John J. Barton and Lee R. Nackman, Addison-Wesley, 1994, ISBN 0-201-53393-6. ¤ MEC++ Rec Reading, P32

The first part of the book explains C++ for FORTRAN programmers (now there's an unenviable task), but the latter parts cover techniques that are relevant in virtually any domain. The extensive material on templates is close to revolutionary; it's probably the most advanced that's currently available, and I suspect that when you've seen the miracles these authors perform with templates, you'll never again think of them as little more than souped-up macros. ¤ MEC++ Rec Reading, P33

Finally, the emerging discipline of patterns in object-oriented software development (see page 123) is described in ¤ MEC++ Rec Reading, P34

Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley, 1995, ISBN 0-201-63361-2. ¤ MEC++ Rec Reading, P35

This book provides an overview of the ideas behind patterns, but its primary contribution is a catalogue of 23 fundamental patterns that are useful in many application areas. A stroll through these pages will almost surely reveal a pattern you've had to invent yourself at one time or another, and when you find one, you're almost certain to discover that the design in the book is superior to the ad-hoc approach you came up with. The names of the patterns here have already become part of an emerging vocabulary for object-oriented design; failure to know these names may soon be hazardous to your ability to communicate with your colleagues. A particular strength of the book is its emphasis on designing and implementing software so that future evolution is gracefully accommodated (see Items 32 and 33). ¤ MEC++ Rec Reading, P36

Design Patterns is also available as a CD-ROM: ¤ MEC++ Rec Reading, P37

Design Patterns CD: Elements of Reusable Object-Oriented Software, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Addison-Wesley, 1998, ISBN 0-201-63498-8. ¤ MEC++ Rec Reading, P38

Magazines ¤ MEC++ Rec Reading, P39

For hard-core C++ programmers, there's really only one game in town: ¤ MEC++ Rec Reading, P40

C++ Report, SIGS Publications, New York, NY. ¤ MEC++ Rec Reading, P41

The magazine has made a conscious decision to move away from its "C++ only" roots, but the increased coverage of domain- and system-specific programming issues is worthwhile in its own right, and the material on C++, if occasionally a bit off the deep end, continues to be the best available. ¤ MEC++ Rec Reading, P42

If you're more comfortable with C than with C++, or if you find the C++ Report's material too extreme to be useful, you may find the articles in this magazine more to your taste: ¤ MEC++ Rec Reading, P43

C/C++ Users Journal, Miller Freeman, Inc., Lawrence, KS. ¤ MEC++ Rec Reading, P44

As the name suggests, this covers both C and C++. The articles on C++ tend to assume a weaker background than those in the C++ Report. In addition, the editorial staff keeps a tighter rein on its authors than does the Report, so the material in the magazine tends to be relatively mainstream. This helps filter out ideas on the lunatic fringe, but it also limits your exposure to techniques that are truly cutting-edge. ¤ MEC++ Rec Reading, P45

Usenet Newsgroups ¤ MEC++ Rec Reading, P46

Three Usenet newsgroups are devoted to C++. The general-purpose anything-goes newsgroup is °comp.lang.c++ . The postings there run the gamut from detailed explanations of advanced programming techniques to rants and raves by those who love or hate C++ to undergraduates the world over asking for help with the homework assignments they neglected until too late. Volume in the newsgroup is extremely high. Unless you have hours of free time on your hands, you'll want to employ a filter to help separate the wheat from the chaff. Get a good filter — there's a lot of chaff. ¤ MEC++ Rec Reading, P47

In November 1995, a moderated version of comp.lang.c++ was created. Named °comp.lang.c++.moderated, this newsgroup is also designed for general discussion of C++ and related issues, but the moderators aim to weed out implementation-specific questions and comments, questions covered in the extensive °on-line FAQ ("Frequently Asked Questions" list), flame wars, and other matters of little interest to most C++ practitioners. ¤ MEC++ Rec Reading, P48

A more narrowly focused newsgroup is °comp.std.c++, which is devoted to a discussion of °the C++ standard itself. Language lawyers abound in this group, but it's a good place to turn if your picky questions about C++ go unanswered in the references otherwise available to you. The newsgroup is moderated, so the signal-to-noise ratio is quite good; you won't see any pleas for homework assistance here. ¤ MEC++ Rec Reading, P49

[edit]

2. An auto_ptr Implementation ¶

Items 9, 10, 26, 31 and 32 attest to the remarkable utility of the auto_ptr template. Unfortunately, few compilers currently ship with a "correct" implementation.1 Items 9 and 28 sketch how you might write one yourself, but it's nice to have more than a sketch when embarking on real-world projects. ¤ MEC++ auto_ptr, P2

Below are two presentations of an implementation for auto_ptr. The first presentation documents the class interface and implements all the member functions outside the class definition. The second implements each member function within the class definition. Stylistically, the second presentation is inferior to the first, because it fails to separate the class interface from its implementation. However, auto_ptr yields simple classes, and the second presentation brings that out much more clearly than does the first. ¤ MEC++ auto_ptr, P3

Here is auto_ptr with its interface documented: ¤ MEC++ auto_ptr, P4

~cpp 
template<class T>
class auto_ptr {
public:
  explicit auto_ptr(T *p = 0);              // see Item 5 for a
                                            // description of "explicit"
  template<class U>                         // copy constructor member
  auto_ptr(auto_ptr<U>& rhs);               // template (see Item 28):
                                            // initialize a new auto_ptr
                                            // with any compatible
                                            // auto_ptr
  ~auto_ptr();
  template<class U>                         // assignment operator
  auto_ptr<T>&                              // member template (see
  operator=(auto_ptr<U>& rhs);              // Item 28): assign from any
                                            // compatible auto_ptr
  T& operator*() const;                     // see Item 28
  T* operator->() const;                    // see Item 28
  T* get() const;                           // return value of current
                                            // dumb pointer
  T* release();                             // relinquish ownership of
                                            // current dumb pointer and
                                            // return its value
  void reset(T *p = 0);                     // delete owned pointer;
                                            // assume ownership of p
private:
  T *pointee;
template<class U>                           // make all auto_ptr classes
friend class auto_ptr<U>;                   // friends of one another
};
template<class T>
inline auto_ptr<T>::auto_ptr(T *p)
: pointee(p)
{}
template<class T>
  inline auto_ptr<T>::auto_ptr(auto_ptr<U>& rhs)
  : pointee(rhs.release())
  {}
template<class T>
inline auto_ptr<T>::~auto_ptr()
{ delete pointee; }
template<class T>
  template<class U>
  inline auto_ptr<T>& auto_ptr<T>::operator=(auto_ptr<U>& rhs)
  {
    if (this != &rhs) reset(rhs.release());
    return *this;
  }
template<class T>
inline T& auto_ptr<T>::operator*() const
{ return *pointee; }
template<class T>
inline T* auto_ptr<T>::operator->() const
{ return pointee; }
template<class T>
inline T* auto_ptr<T>::get() const
{ return pointee; }
template<class T>
inline T* auto_ptr<T>::release()
{
  T *oldPointee = pointee;
  pointee = 0;
  return oldPointee;
}
template<class T>
inline void auto_ptr<T>::reset(T *p)
{
  if (pointee != p) {
    delete pointee;
    pointee = p;
  }
}

Here is auto_ptr with all the functions defined in the class definition. As you can see, there's no brain surgery going on here: ¤ MEC++ auto_ptr, P5

~cpp 
template<class T>
class auto_ptr {
public:
  explicit auto_ptr(T *p = 0): pointee(p) {}
  template<class U>
  auto_ptr(auto_ptr<U>& rhs): pointee(rhs.release()) {}
  ~auto_ptr() { delete pointee; }
  template<class U>
  auto_ptr<T>& operator=(auto_ptr<U>& rhs)
  {
    if (this != &rhs) reset(rhs.release());
    return *this;
  }
  T& operator*() const { return *pointee; }
  T* operator->() const { return pointee; }
  T* get() const { return pointee; }
  T* release()
  {
    T *oldPointee = pointee;
    pointee = 0;
    return oldPointee;
  }
  void reset(T *p = 0)
  {
    if (pointee != p) {
      delete pointee;
      pointee = p;
    }
  }
  private:
    T *pointee;

  template<class U> friend class auto_ptr<U>;
  };

If your compilers don't yet support explicit, you may safely #define it out of existence: ¤ MEC++ auto_ptr, P6

~cpp 
#define explicit

This won't make auto_ptr any less functional, but it will render it slightly less safe. For details, see Item 5. ¤ MEC++ auto_ptr, P7

If your compilers lack support for member templates, you can use the non-template auto_ptr copy constructor and assignment operator described in Item 28. This will make your auto_ptrs less convenient to use, but there is, alas, no way to approximate the behavior of member templates. If member templates (or other language features, for that matter) are important to you, let your compiler vendors know. The more customers ask for new language features, the sooner vendors will implement them. ¤ MEC++ auto_ptr, P8

MoreEffectiveC++

More EffectiveC++/Appendix

Contents

1. Recommended Reading ¶

1.1. Books ¶

2. An auto_ptr Implementation ¶