>le 2001/10/17 15:39, tedd à tedd@... a écrit :
>
>>  Please explain if there are other types of memory leaks.
>
>your description is exact, except in your description the agent responsible
>for the leak is murphy.

No, then it's not a "memory leak". What you're describing is sloppy
programming habits, not that I am above that sort of thing.

What you really mean in your "memory leak" explanation is that once
you start assigning and releasing memory it becomes difficult to keep
track of what's being used and what isn't. And, therein, if there are
differences in allocations and reclaimed memory, then that's the
reason for memory being eaten up or "leaked".

I remember that you have a system once that counted the number of
times you allocated and released memory which I thought was
interesting. It assumed (if I remember correctly) that if the number
of times of allocation equaled the number of times of released memory
then everything was Okay. The only fault to that algorithm was if one
allocated x five times and y three times ( x <> y) and then released
x and y each four times would result in a "memory leak".

I could see a memory allocator (not manager) that would keep track of
the amount (not times) of memory allocated and released to point out
possible problems. However, my code/logic seldom has that problem
because I always think in terms of what is needed and when it's to be
released before it's assigned -- just a matter of habit and I seldom
have a memory "leak" problem as described (I suggest a more useful
term would be "memory drain").

However, to get back to the point -- when one uses the term "memory
leak",  it infers that there is some internal flaw to the language
that doesn't deal with memory allocations correctly and therein my
objection to its use when talking about FB. I suggest that we use
some other term to describe the problem -- remembering that the fault
lies with us and not FB.

tedd

--
http://sperling.com