Prev: Code Review? memory management in C
Next: error LNK2001: unresolved external symbol _iplGetPixel@16
From: res7cxbi on 9 Feb 2006 18:47
As a slight beginner, I would like to know how to avoid memory leaks in
the first place so that i don't have to find them and get rid of them
after the code is done. I know this has to do a lot with garbage
collection, i just like to know how to avoid memory leaks all together
- any tips or suggestions?

thanks in advance

From: Jim Langston on 9 Feb 2006 19:01
<res7cxbi(a)verizon.net> wrote in message
news:1139528874.334822.162120(a)z14g2000cwz.googlegroups.com...
> As a slight beginner, I would like to know how to avoid memory leaks in
> the first place so that i don't have to find them and get rid of them
> after the code is done. I know this has to do a lot with garbage
> collection, i just like to know how to avoid memory leaks all together
> - any tips or suggestions?
>
> thanks in advance

Don't use new or new[] unless you have to.
If you use new, use delete.
If you use new[] use delete[].
If you use new/new[] do not make the pointer pointing to this memory point
to anything else unless you first call delete/delete[]
General rule, the object/function that uses new/new[] also uses
delete/delete[] unless you have a very good reason not to.
Use new and delete instead of malloc/release as the math is easier and you
aren't as apt to make mistakes.


From: Francis Glassborow on 9 Feb 2006 20:04
In article <1139528874.334822.162120(a)z14g2000cwz.googlegroups.com>,
res7cxbi(a)verizon.net writes
>As a slight beginner, I would like to know how to avoid memory leaks in
>the first place so that i don't have to find them and get rid of them
>after the code is done. I know this has to do a lot with garbage
>collection, i just like to know how to avoid memory leaks all together
>- any tips or suggestions?

Never dynamically allocate memory:-) Avoid using setjmp/longjmp
Avoid signals.

If memory is allocated in a function, release it in the same function.
If that is not reasonable add the function to the set of allocating
functions and treat a call to such functions as allocation and ensure
that the memory it allocates is released before you exit the function
that calls it. This is recursive.

For example if you call strdup (note that it isn't a standard function
though it is widely available) remember that it allocates dynamic
resources for the returned 'string' and so it is an allocating function
and the caller is responsible for releasing those resources.


--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
From: Francis Glassborow on 9 Feb 2006 20:08
In article <SJQGf.69$UW2.7(a)fe03.lga>, Jim Langston
<tazmaster(a)rocketmail.com> writes
>Don't use new or new[] unless you have to.
>If you use new, use delete.
>If you use new[] use delete[].
>If you use new/new[] do not make the pointer pointing to this memory point
>to anything else unless you first call delete/delete[]
>General rule, the object/function that uses new/new[] also uses
>delete/delete[] unless you have a very good reason not to.
>Use new and delete instead of malloc/release as the math is easier and you
>aren't as apt to make mistakes.

OK, assuming the OP was concerned with C++:

Ignore the above but instead:

1) Always ensure that dynamic objects (ones created with the new
expression) are encapsulated in an object (usually a smart pointer)
whose destructor releases them with a use of the delete expression.

2) Never use new[] but use a std::vector instead.

The delete expression should virtually never be visible in application
level code. If it is it is a leak waiting to happen.




--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
From: Jim Langston on 9 Feb 2006 20:39

"Francis Glassborow" <francis(a)robinton.demon.co.uk> wrote in message
news:ntbGlVXpe+6DFwA8(a)robinton.demon.co.uk...
> In article <SJQGf.69$UW2.7(a)fe03.lga>, Jim Langston
> <tazmaster(a)rocketmail.com> writes
>>Don't use new or new[] unless you have to.
>>If you use new, use delete.
>>If you use new[] use delete[].
>>If you use new/new[] do not make the pointer pointing to this memory point
>>to anything else unless you first call delete/delete[]
>>General rule, the object/function that uses new/new[] also uses
>>delete/delete[] unless you have a very good reason not to.
>>Use new and delete instead of malloc/release as the math is easier and you
>>aren't as apt to make mistakes.
>
> OK, assuming the OP was concerned with C++:
>
> Ignore the above but instead:
>
> 1) Always ensure that dynamic objects (ones created with the new
> expression) are encapsulated in an object (usually a smart pointer) whose
> destructor releases them with a use of the delete expression.

I see. And your dynamic objects encapsulated in a class don't use new to
allocate them. Interesting.

> 2) Never use new[] but use a std::vector instead.

I see. Use a vector for polymorphism. Without using new anywhere.

> The delete expression should virtually never be visible in application
> level code. If it is it is a leak waiting to happen.

True.

Now, what of your 3 statements contradicts my 6 statements? In all 3 of
your statements, my 6 statements have to be taken into account. Or don't
your classes that encapsolate dynamic objects use new and delete? And if
they use new[] they use delete[]? And doesn't your class that creates the
dynamic object with new also the same class that uses delete to free the
memory?

Insted of "Ignore the above but instead:"
try
"In addition to the above:"


 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: Code Review? memory management in C
Next: error LNK2001: unresolved external symbol _iplGetPixel@16