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 accidently 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; // 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. 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. 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 deallocation is performed by operator delete, the deallocation analogue of operator new. (For details, see "A Note About Placement new and Placement delete" at the end of this article.)
It is this relationship between new expressions and operator delete 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:
// see below for a discussion of why
// this isn't quite right
class Counter {
public:
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, as in:
// 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, as in:
// 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. 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 now can go in header
The first Widget implementation choice now looks like:
// embed a Counter to count objects
class Widget {
public:
.....
static size_t howMany()
{return Counter<Widget>::howMany();}
private:
.....
Counter<Widget> c;
};
And the second choice now looks like:
// inherit from Counter to count objects
class Widget: public Counter<Widget> {
.....
};
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" [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.
