Check for memory Vulnerabilities--cmemorystate

You may already know that pointer problems in C + + and C are a headache for memory applications and releases. If you apply for memory, but do not release, and your program needs to run for a long time, then the system will gradually reduce the resources, when the system's resources are exhausted, the system will collapse. Therefore, in the process of developing the program must ensure the full release of resources. Here's a review of the memory vulnerabilities.
You may ask how the system supports the memory leak check. In fact, all the functions related to memory allocation in your version of debug are overloaded, and the process is that when your program is applying for memory, it first calls the general memory allocation function to allocate a slightly larger chunk of memory. In this memory block is divided into four small pieces: Heap information, buffer, User memory blocks, buffer. The first block is information about the heap, such as the location where the memory is requested (filename, line number), the type of memory block (such as Integer, floating point, or object of a certain class), and so on. The second block is a buffer that intercepts the user's request for memory usage beyond the bounds. The third block is the memory that is really given to the user, and the returned pointer points here. Block four is also a buffer that acts the same as the second block.
When the memory you are applying for is recorded, it's easier to check for a memory leak, roughly, if you want to check if there is a memory leak in a certain segment, you just need to ask the system to do a memory usage image for you at the beginning of the program, and record the memory usage at the beginning of the program. Then at the end of the program to make the system for you to do a memory image, compare two images, to check whether there is no release of memory, if there is not free memory, according to this piece of information about the distribution of the user is not released from the requested memory.
Specifically, checking for memory vulnerabilities requires the following steps:
Create a CMemoryState object at the beginning of the program segment you are detecting, call its member function checkpoint, to obtain a snapshot of the current memory usage; Create a CMemoryState object at the end of the program segment you are detecting, call its member function checkpoint to get a snapshot of the current memory usage, and then create a third CMemoryState object, call its member function difference, Takes the first CMemoryState object and the second Cmemeorystate object as its arguments. If two memory snapshots are different, the function returns Non-zero, indicating that there are memory vulnerabilities in this program segment. Let's take a look at a typical example:
//Declare the variables needed

#ifdef _DEBUG

CMemoryState oldmemstate, Newmemstate, diffmemstate;

Oldmemstate.checkpoint ();

#endif

Do your memory allocations and deallocations ...

CString s = "This is a frame variable";

The next object is a heap object

cperson* p = new CPerson ("Smith", "Alan", "581_0215");

#ifdef _DEBUG

Newmemstate.checkpoint ();

if (Diffmemstate.difference (Oldmemstate, newmemstate))

{

TRACE ("Memory leaked!/n");

}
#endif