Memory leak prevention methodogies

[c___newbie]

Hi all,
I’m studying a problem releated to memory leakage.
Now, there are many tools to check memory leakake at run-time (dynamic analysis), and some tools can check memory leakage at compile-time (static analysis). But I have some questions:
How do you think to prevent memory leakage from coding phase (without using tool)? (or In coding phase, what do you have to do to prevent memory leakage?)
I want to investigate from many programmers in many countries.
Can you help me?

[WingedPanther]

The basic technique is to make sure that for every malloc() there is a corresponding free(). This takes care of the most obvious problem, but is far from error proof. For example, if you have code like the following:

int * ptr;
for (i=1;i<10;i++){ptr=malloc(int);}
free(ptr);

will leak memory like crazy because the malloc is inside the loop, but the free is outside the loop.
This type of situation can happen easily when dealing with data structures such as linked lists, where you'll have a pointer to the head of the list and the current node of the list, and each node has a pointer to the next node. When "deleting" the linked list you have to be very careful to free each node without losing access to the list in the process.

[G_Morgan]

I get lazy and use garbage collection. Let someone else worry about memory management .

As I see it. Unless I need programs that are always instantly responsive (i.e. 10ms pauses are unacceptable) then there is little or no reason not to use conservative GC. It does not produce an overly undue overhead in terms of processor time (because the majority of the deallocation code is only called once per thousands of deallocations while with manual memory management it's called once per deallocation). The only real issue is that GC can cause intense spots of activity where the program locks up. This is not usually noticeable in most applications.

A lot of C++ programmers use smart pointers to implement reference counting GC. This can work at a near manual level of efficiency. The only issue is circular references but it does generally stabilise memory usage. For me that is the key, I want to be able to tell people that this application uses N MiB of memory. I don't care that it wastes O MiB as long as it wastes O statically and no more than O.