Bonus: Checking Memory Operators
I needed a memory checking tool while working for a complex project which was heavily using the memory operators. Initially, I tried to overload the memory operators to check them. However, I had run into compilation problems. It occurred to me to leverage my CProfiler class for this purpose. So, I updated the class; the second parameter of the CProfiler::InitClass() specifies the usage. If it is true, the class will be used for profiling the application, else it will be used to check the memory operators and I overloaded the constructor. Then, I defined several macros; see Listing Six.
#define MEMORY_NEW(ptr,ptrtype,id) CProfiler mem_new(ptr, L##ptrtype, L"new", L##id) #define MEMORY_NEW_ARR(ptr,ptrtype,id) CProfiler mem_new_arr(ptr, L##ptrtype, L"new[]", L##id) #define MEMORY_DELETE(ptr,ptrtype,id) CProfiler mem_delete(ptr, L##ptrtype, L"delete", L##id) #define MEMORY_DELETE_ARR(ptr,ptrtype,id) CProfiler mem_delete_arr(ptr, L##ptrtype, L"delete[]", L##id)
At the site of each new, delete, new[], and delete[] operator calls, the appropriate macro should be used; see Listing Seven.
int main(int argc, char* argv[])
{
PROFILER_INITCLASS_CURRDIR;
int* pInt = new int;
char* pChar = new char[100];
MEMORY_NEW(pInt, "int", "main"); // respectively Address,Type,Id
MEMORY_NEW_ARR(pChar, "char", "main");
delete pInt;
delete [] pChar;
MEMORY_DELETE(pInt, "int", "main");
MEMORY_DELETE_ARR(pChar, "char", "main");
PROFILER_PROCESSDATA;
return 0;
}
Certainly, adding them is a very boring task! That's why I created another tool, ProcessMemoryData.hta, to process the memory data thus collected. This tool imports the selected CSV file, creates an XLS file in its folder named after its name, sorts all the data and gives a report on the mismatching new/delete and new[]/delete[] uses for each address and type. Its user interface is similar to the ProcessProfilingData.hta.
Conclusion
Users are expected to run the profiled applications many times under different conditions. Here, the conditions depend on the computer on which the application runs: operating system, number of processes running, network connections, available physical and virtual memories, CPU power, and so on. Perhaps it is a good idea to define a "typical" condition and specifically analyze the application under this condition. For consistent results, the users should stop other applications that execute at random intervals. Moreover, the users should profile only the specific areas of interest. For example, it may be meaningless to profile the GUI part of the application. The complex algorithms are the prime targets for profiling. The user may discover opportunities to improve them by studying the profiler data carefully. It is at this point that you'll likely find the CProfiler class most useful.
