counting.htm

一个非常适合初学者入门的有关c++的文档

 Counting Objects in C++ This is a slightly-modified version of an article that appeared in the April 1998 issue of the C/C++ Users Journal.
Counting Objects in C++
by Scott Meyers
Sometimes easy things are easy, but they're still subtle. For example, suppose you have a class Widget, and you'd like to have a way to find out at run time how many Widget objects exist. An approach that's both easy to implement and that gives the right answer is to create a static counter in Widget, increment the counter each time a Widget constructor is called, and decrement it whenever the Widget destructor is called. You also need a static member function howMany to report how many Widgets currently exist. If Widget did nothing but track how many of its type exist, it would look more or less like this: 
class Widget {
public:
  Widget() { ++count; }
  Widget(const Widget&) { ++count; }
  ~Widget() { --count; }

  static size_t howMany()
  { return count; }

private:
  static size_t count;
};

// obligatory definition of count. This
// goes in an implementation file
size_t Widget::count = 0;

This works fine. The only mildly tricky thing is to remember to implement the copy constructor, because a compiler-generated copy constructor for Widget wouldn't know to increment count.
If you had to do this only for Widget, you'd be done, but counting objects is something you might want to implement for several classes. Doing the same thing over and over gets tedious, and tedium leads to errors. To forestall such tedium, it would be best to somehow package the above object-counting code so it could be reused in any class that wanted it. The ideal package would: Be easy to use require minimal work on the part of class authors who want to use it. Ideally, they shouldn't have to do more than one thing, that is, more than basically say "I want to count the objects of this type." Be efficient impose no unnecessary space or time penalties on client classes employing the package. Be foolproof be next to impossible to accidentally yield a count that is incorrect. (We're not going to worry about malicious clients, ones who deliberately try to mess up the count. In C++, such clients can always find a way to do their dirty deeds.)
Stop for a moment and think about how you'd implement a reusable object-counting package that satisfies the goals above. It's probably harder than you expect. If it were as easy as it seems like it should be, you wouldn't be reading an article about it in this magazine.
new, delete, and Exceptions
While you're mulling over your solution to the object-counting problem, allow me to switch to what seems like an unrelated topic. That topic is the relationship between new and delete when constructors throw exceptions. When you ask C++ to dynamically allocate an object, you use a new expression, as in: class ABCD { ... };     // ABCD = "A Big Complex Datatype"
ABCD *p = new ABCD;     // "new ABCD" is a new expression

The new expression whose meaning is built into the language and whose behavior you cannot change does two things. First, it calls a memory allocation function called operator new. That function is responsible for finding enough memory to hold an ABCD object. If the call to operator new succeeds, the new expression then invokes an ABCD constructor on the memory that operator new found.
But suppose operator new throws a std::bad_alloc exception: 
ABCD *p = new ABCD;     // suppose a std::bad_alloc is thrown here


Exceptions of this type indicate that an attempt to dynamically allocate memory has failed. In the new expression above, there are two functions that might give rise to that exception. The first is the invocation of operator new that is supposed to find enough memory to hold an ABCD object. The second is the subsequent invocation of the ABCD constructor that is supposed to turn the raw memory into a valid ABCD object.
If the exception came from the call to operator new, no memory was allocated. However, if the call to operator new succeeded and the invocation of the ABCD constructor led to the exception, it is important that the memory allocated by operator new be deallocated. If it's not, the program has a memory leak, because it's not possible for the client the code requesting creation of the ABCD object to determine which function gave rise to the exception.
For many years this was a hole in the draft C++ language specification, but in March 1995 the C++ Standards committee adopted the rule that if, during a new expression, the invocation of operator new succeeds and the subsequent constructor call throws an exception, the runtime system must automatically deallocate the memory that operator new allocated. This de-allocation is performed by operator delete, the de-allocation analogue of operator new. (For details, see the sidebar on placement new and placement delete.)
It is this relationship between new expressions and operator delete that affects us in our attempt to automate the counting of object instantiations.
Counting Objects
In all likelihood, your solution to the object-counting problem involved the development of an object-counting class. Your class probably looks remarkably like perhaps even exactly like the Widget class I showed earlier: class Counter {                   // see below for a discussion of
public:                           // why this isn't quite right
  Counter() { ++count; }
  Counter(const Counter&) { ++count; }
  ~Counter() { --count; }

  static size_t howMany()
  { return count; }

private:
  static size_t count;
};

// This still goes in an
// implementation file
size_t Counter::count = 0;

The idea here is that authors of classes that need to count the number of objects in existence simply use Counter to take care of the bookkeeping. There are two obvious ways to do this. One way is to define a Counter object as a class data member, like this: // embed a Counter to count objects
class Widget {
public:
  ...                             // all the usual public Widget stuff

  static size_t howMany()
  { return Counter::howMany(); }
private:
  ...                             // all the usual private Widget stuff
  Counter c;
};

The other way is to declare Counter as a base class, like this: // inherit from Counter to count objects
class Widget: public Counter {
  ...                             // all the usual public Widget stuff
private:
  ...                             // all the usual private Widget stuff
};

Both approaches have advantages and disadvantages. But before we examine them, we need to observe that neither approach will work in its current form. The problem has to do with the static object count inside Counter. There's only one such object, but we need one for each class using Counter. For example, if we want to count both Widgets and ABCDs, we need two static size_t objects, not one. Making Counter::count nonstatic doesn't solve the problem, because we need one counter per class, not one counter per object.
We can get the behavior we want by employing one of the best-known but oddest-named tricks in all of C++: we turn Counter into a template, and each class using Counter instantiates the template with itself as the template argument.
Let me say that again. First, Counter becomes a template: template<typename T>
class Counter {
public:
  Counter() { ++count; }
  Counter(const Counter&) { ++count; }
  ~Counter() { --count; }

  static size_t howMany()
  { return count; }

private:
  static size_t count;
};

template<typename T>
size_t Counter<T>::count = 0;              // this may now go in a header file

The first Widget implementation choice then looks like this: class Widget {                             // embed a Counter to count objects
public:
  ...

  static size_t howMany()
  {return Counter<Widget>::howMany();}
private: