Talking about the memory leak
A memory leak is a common and troubling problem for a C + + programmer. Many techniques have been developed to deal with this problem, such as Smart Pointer,garbage collection. Smart pointer technology is more mature, the STL already contains the class to support the smart pointer, but it does not seem to be widely used, and it does not solve all the problems; garbage collection technology has matured in Java, However, the development of the C + + domain is not smooth, although it is very early to think in C + + also joined the GC support. The real world is like this, as a C/s + + programmer, memory leaks is your heart forever pain. Fortunately, however, there are a number of tools that can help us verify the existence of the memory leak and find the code for the problem.
Definition of memory leaks
In general we often say that the memory leak is the heap memory leakage. Heap memory is that the program is allocated from the heap, of any size (the size of the memory block can be determined during the program run), and the freed memory must be displayed after use. The application generally uses functions such as malloc,realloc,new to allocate a piece of memory from the heap, and after use, the program must be responsible for the corresponding call free or delete to release the memory block, otherwise, this piece of memory can not be reused, we say this memory leak. The following applet demonstrates a scenario in which heap memory leaks:
void MyFunction(int nSize)
{
char* p= new char[nSize];
if( !GetStringFrom( p, nSize ) ){
MessageBox(“Error”);
return;
}
…//using the string pointed by p;
delete p;
}
Example One
When the function Getstringfrom () returns zero, the memory pointed to by the pointer P is not released. This is a common scenario where memory leaks occur. The program allocates memory at the entrance, releasing the memory at the exit, but the C function can exit anywhere, so that a memory leak occurs when there is no release of the memory that should be freed at an exit.
In a broad sense, memory leaks include not only the leak of heap memory, but also the leakage of system resources (resource leak), such as the kernel mentality Handle,gdi object,socket, interface, etc., fundamentally these objects allocated by the operating system also consume memory, Leakage of these objects can eventually result in memory leaks. Also, some objects consume kernel-mindset memory, which can cause the entire operating system to become unstable when the objects are compromised. In contrast, system resource leaks are more severe than heap memory leaks.
The leakage of GDI object is a common resource leak:
void CMyView::OnPaint( CDC* pDC )
{
CBitmap bmp;
CBitmap* pOldBmp;
bmp.LoadBitmap(IDB_MYBMP);
pOldBmp = pDC->SelectObject( &bmp );
…
if( Something() ){
return;
}
pDC->SelectObject( pOldBmp );
return;
}
When the function something () returns Non-zero, the program does not select the Poldbmp back into the PDC before exiting, which causes the Hbitmap object that poldbmp points to leak. This program, if run for a long time, may cause the entire system to spend screen. This problem is more easily exposed under Win9x because the Win9x GDI heap is much smaller than Win2K or NT.