counting.htm

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

  ...
  Counter<Widget> c;
};


And the second choice now looks like: 
class Widget: public Counter<Widget> {      // inherit from Counter
public:                                     // to count objects
  ...
};


Notice how in both cases we replace Counter with Counter<Widget>. As I said earlier, each class using Counter instantiates the template with itself as the argument.
The tactic of a class instantiating a template for its own use by passing itself as the template argument was first publicized by Jim Coplien. He showed that it's used in many languages (not just C++) and he called it "a curiously recurring template pattern" [Reference 1]. I don't think Jim intended it, but his description of the pattern has pretty much become its name. That's too bad, because pattern names are important, and this one fails to convey information about what it does or how it's used.
The naming of patterns is as much art as anything else, and I'm not very good at it, but I'd probably call this pattern something like "Do It For Me." Basically, each class generated from Counter provides a service (it counts how many objects exist) for the class requesting the Counter instantiation. So the class Counter<Widget> counts Widgets, and the class Counter<ABCD> counts ABCDs.
Now that Counter is a template, both the embedding design and the inheritance design will work, so we're in a position to evaluate their comparative strengths and weaknesses. One of our design criteria was that object-counting functionality should be easy for clients to obtain, and the code above makes clear that the inheritance-based design is easier than the embedding-based design. That's because the former requires only the mentioning of Counter as a base class, whereas the latter requires that a Counter data member be defined and that howMany be re-implemented by clients to invoke Counter's howMany. (An alternative is to omit Widget::howMany and make clients call Counter<Widget>::howMany directly. For the purposes of this article, however, we'll assume we want howMany to be part of the Widget interface.) That's not a lot of additional work (client howManys are simple inline functions), but having to do one thing is easier than having to do two. So let's first turn our attention to the design employing inheritance.
Using Public Inheritance
The design based on inheritance works because C++ guarantees that each time a derived class object is constructed or destroyed, its base class part will be constructed first and destroyed last. Making Counter a base class thus ensures that a Counter constructor or destructor will be called each time a class inheriting from it has an object created or destroyed.
Any time the subject of base classes comes up, however, so does the subject of virtual destructors. Should Counter have one? Well-established principles of object-oriented design for C++ dictate that it should. If it has no virtual destructor, deletion of a derived class object via a base class pointer yields undefined (and typically undesirable) results (Item E14): 
class Widget: public Counter<Widget> { ... };

Counter<Widget> *pw =              // get base class ptr to
  new Widget;                      // derived class object

...
delete pw;                         // yields undefined results if Counter<Widget>
                                   // lacks a virtual destructor


Such behavior would violate our criterion that our object-counting design be essentially foolproof, because there's nothing unreasonable about the code above. That's a powerful argument for giving Counter a virtual destructor.
Another criterion, however, was maximal efficiency (imposition of no unnecessary speed or space penalty for counting objects), and now we're in trouble. We're in trouble because the presence of a virtual destructor (or any virtual function) in Counter means each object of type Counter (or a class derived from Counter) will contain a (hidden) virtual pointer, and this will increase the size of such objects if they don't already support virtual functions. (For details, see Item M24.) That is, if Widget itself contains no virtual functions, objects of type Widget would increase in size if Widget started inheriting from Counter<Widget>. We don't want that.
The only way to avoid it is to find a way to prevent clients from deleting derived class objects via base class pointers. It seems that a reasonable way to achieve this is to declare operator delete private in Counter: 
template<typename T>
class Counter {
public:
  ...
private:
  void operator delete(void*);
  ...
};


Now the delete expression won't compile: 
class Widget: public Counter<Widget> { ... };
Counter<Widget> *pw = new Widget;
...
delete pw;                          // error! Can't call private
				    // operator delete


Unfortunately and this is the really interesting part the new expression shouldn't compile either! 
Counter<Widget> *pw =               // this should not compile because
  new Widget;                       // operator delete is private!


Remember from my earlier discussion of new, delete, and exceptions that C++'s runtime system is responsible for de-allocating memory allocated by operator new if the subsequent constructor invocation fails. Recall also that operator delete is the function called to perform the deallocation. But we've declared operator delete private in Counter, which makes it invalid to create objects on the heap via new!
Yes, this is counterintuitive, and don't be surprised if your compilers don't yet support this rule, but the behavior I've described is correct. Let us therefore consider a different way of preventing the deletion of derived class objects via Counter* pointers. Let us consider making Counter's destructor protected: 
template<typename T>
class Counter {
...
protected:
  ~Counter();
  ...
...
};

class Widget: public Counter<Widget> { ... };
Counter<Widget> *pw = new Widget;
...
delete pw;                     // error! Can't call protected
                               // destructor


This offers the behavior we want. We can still create Widget objects, and we can still destroy them, as long as we don't do it via Counter* pointers. When we destroy a static Widget or a stack-based Widget, the implicit call to the Counter destructor is attributed to the Widget destructor, and since the Widget destructor is a member function of a derived class, it has access to Counter's protected members. Similarly, when we delete a Widget through a Widget* pointer, the implicit call to the Counter destructor is attributed to the Widget destructor.
Unfortunately, this design smells a bit of Bait and Switch. By having Widget publicly inherit from Counter, we're saying that every Widget object isa Counter object (Item E35). As a result, Widget* pointers are implicitly and automatically converted to Counter* pointers whenever it's necessary. Widget clients can thus be forgiven for expecting that they can delete Widgets via base class pointers; it's just one of the things public inheritance implies. Yet the above design disallows it. We get the behavior we want, yes, and that's worth a lot, but it just doesn't feel right. (The earlier design the one involving a private operator delete exhibits the same undesireable behavior.)
Preventing deletion of derived class objects via public base class pointers looks unsatisfactory no matter how we slice it. I say we abandon this approach and turn our attention to using a Counter data member instead.
Using a Data Member
We've already seen that the design based on a Counter data member has one drawback: clients must both define a Counter data member and write an inline version of howMany that calls the Counter's howMany function. That's marginally more work than we'd like to impose on clients, but it's hardly unmanageable. There is another drawback, however. The addition of a Counter data member to a class will often increase the size of objects of that class type.
At first blush, this is hardly a revelation. After all, how surprising is it that adding a data member to a class makes objects of that type bigger? But blush again. Look at the definition of Counter: 
template<typename T>
class Counter {
public:
  Counter();
  Counter(const Counter&);
  ~Counter();

  static size_t howMany();
private:
  static size_t count;
};


Notice how it has no nonstatic data members. That means each object of type Counter contains nothing. Might we hope that objects of type Counter have size zero? We might, but it would do us no good. C++ is quite clear on this point. All objects have a size of at least one byte, even objects with no nonstatic data members. By definition, sizeof will yield some positive number for each class instantiated from the Counter template. So each client class containing a Counter object will contain more data than it would if it didn't contain the Counter.
(Interestingly, this does not imply that the size of a class without a Counter will necessarily be bigger than the size of the same class containing a Counter. That's because alignment restrictions can enter into the matter. For example, if Widget is a class containing two bytes of data but that's required to be four-byte aligned, each object of type Widget will contain two bytes of padding, and sizeof(Widget) will return 4. If, as is common, compilers satisfy the requirement that no objects have zero size by inserting a char into Counter<Widget>, it's likely that sizeof(Widget) will still yield 4 even if Widget contains a Counter<Widget> object. That object will simply take the place of one of the bytes of padding that Widget already contained. This is not a terribly common scenario, however, and we certainly can't plan on it when designing a way to package object-counting capabilities.)
I'm writing this at the very beginning of the Christmas season. (It is in fact Thanksgiving Day, 1997, which gives you some idea of how I celebrate major holidays...) Already I'm in a Bah Humbug mood. All I want to do is count objects, and I don't want to haul along any extra baggage to do it. There has got to be a way.
Using Private Inheritance
Look again at the inheritance-based code that led to the need to consider a virtual destructor in Counter: class Widget: public Counter<Widget>
{ ... };

Counter<Widget> *pw = new Widget;