Re: Tracking Object Creation and Destruction
On 2/8/07 12:03 AM, in article 7rpq94-uim.ln1@wheat.betterworld.us, "Ross
Boylan" <ross@biostat.ucsf.edu> wrote:
Thomas Richter wrote:
Ross Boylan wrote:
I would like to be able to do the following test automatically, as part
of a test suite:
initializeCounts();
exerciseTest();
checkCounts();
The counts would be things like "class A had 10 instances allocated and
10 freed." That is, they are on a class basis. Mostly, I want to be
sure that all A's created in the course of the test are freed afterward.
Any advice? In particular, is there some code that would be a good
basis for doing such things, and how could it be adapted? The rest of
this message summarizes my review so far.
Thus, your requirement is
a) no major code changes for existing code and
Yes. Modifications, for example using templates, whether with the method
Otis outlined earlier in this thread or those in the "templates,
constructors, and references" thread starting 2007-01-30, get awkward. And
I wouldn't want the code modifications for testing to be part of the
regular version of the program.
The principal shortcoming of each of two solutions cited was not the use of
a class template - but rather the use of inheritance to implement the
solution. After all, program instrumentation should have as little effect as
possible on the program it is observing - both to ensure the accuracy of the
data collected and to ensure that the instrumentation code itself can be
safely removed in the shipping version of the program. Therefore any
solution that requires temporarily replacing an existing class (or
temporarily changing the class hierarchy of the program) is probably too
significant a change to justify solely on the grounds of program
instrumentation. While it is true that the aim of every program is to be
correct, it is also true that no program has as its primary goal - the
ability to self-test for correctness. So program instrumentation is only
justified as long as it does not interfere with fulfilling the primary
purpose of the program (whatever that purpose may be).
As an example of what I'm currently doing with a template solution, I have a
Factory class that is supposed to be smart about recycling objects. The
rest of the program only gets and releases Nodes through the Factory. So
one test asks the Factory for 20 Nodes, releases them, and then asks for 10
more. The I have a Boost test check that the total number of Nodes
allocated is 20, not 30 (i.e., that I'm recycling the old Nodes).
The solution I would suggest relies on containment (adding a data member)
then on inheritance. Containment is usually a better strategy than
inheritance for adding a new capability to a class (see this Herb Sutter
article for some good supporting arguments:
http://www.gotw.ca/publications/mill06.htm ) In particular, adding a
"ObjectCounter" data member to the class (I believe) would be reasonably
limited in its effects so that it could be justified.
This new data member would simply record its own construction and
destruction as a proxy for its enclosing object's construction and
destruction. So the constructing, copying and assignment of this data member
would be incidental to the construction, copying or assignment of the object
itself. In other words, the data member merely observes those operations
that would take place even if the data member did not exist. In this way the
role of the data member is that of an observer - and not as a participant in
the program's execution.
As noted above, it is important that this instrumentation have a limited
effect upon the program itself. In this regard, the two principal effects of
adding this data member would be: first, a nominal increase in the size of
the class object (because even though the data member class is empty, the
data member must still occupy storage within its object) and second: a
nominal amount of additional overhead when constructing, copying or
assigning an object of the class being instrumented. Now there is no reason
to expect that either of the changes would affect the correctness of the
program itself - or if they did, it would have to be due to an error in the
program itself (such hard-coding the the size of the class object instead of
using the sizeof() operator) and not the fault of the instrumentation code
itself. And as long as the effects of the instrumentation are limited in
this way: removing this data member (in the shipping build of the program)
should be a safe change to make.
One slightly tricky aspect to the implementation of the "ObjectCounter" data
member would be to distinguish properly copy-construction from assignment.
Clearly only the former operation should be counted as construction and the
latter, not. The code below illustrates how a ObjectCounter data member
might be implemented:
#include <iostream>
template <class T>
struct ObjectCounter
{
ObjectCounter()
{
++sObjectCount;
}
ObjectCounter(const ObjectCounter& )
{
++sObjectCount;
}
~ObjectCounter() { --sObjectCount; }
ObjectCounter& operator=(const ObjectCounter&)
{
// do not increment sObjectCount
return *this;
}
static int CountObjects()
{
return sObjectCount;
}
private:
static int sObjectCount;
};
template <class T>
int ObjectCounter<T>::sObjectCount;
// Class of objects to be counted
class A
{
public:
A() : i(0) {}
A(const A&) : i(0) {}
private:
int i;
ObjectCounter<A> counter;
};
using std::cout;
int main(int argc, char *argv[])
{
{
A a1;
A a2;
A a3 = a1; // count as construction
a1 = a2; // do not count as construction
cout << ObjectCounter<A>::CountObjects();
cout << " A objects\n";
}
cout << ObjectCounter<A>::CountObjects();
cout << " A objects\n";
}
Program Output:
3 A objects
0 A objects
Greg
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]