memory allocation

[Liber]

In article <28893 at think.UUCP> barmar at kulla.think.com.UUCP (Barry Margolin) writes:
>In article <6913 at cdis-1.uucp> tanner at cdis-1.uucp (Dr. T. Andrews) writes:
>>I don't mind the small expense at free() time, because in general
>>that's not done nearly as often as malloc() in my applications.

>Shouldn't you free everything you allocate?  Or do you just depend on
>everything being freed when you exit?

In my experience, free()s are done much less often than malloc()s (As
a matter of fact, the best case is when # free()s invoked = # malloc()s
invoked).

>From what I have seen, memory is usually malloc()ed for one or more of the
following reasons (I don't necessarily agree with all of these reasons,
but this is based upon code I have seen and not just code that I have
written):

1.  The amount of space needed is variable.

2.  The amount of space needed is unknown at compile time.

3.  The data needs to be shared between different functions.

4.  The data needs to live through more than one function invocation
(and static variables may not suffice because the data used may depend
on where a given function is called from)

5.  Space for some variables may not be allocated unless they are going
to be specifically used.

If you are using malloc() for either reason #3 or reason #4, the number
of free()s will usually be much less than the number of malloc()s.
It isn't worth cleaning up the heap before exit(), since exit() (at
least on Unix), does it for you.
-- 
 _ __		NEVIN J. LIBER  ..!att!ihlpb!nevin1  (312) 979-4751  IH 4F-410
' )  )  "I catch him with a left hook. He eels over. It was a fluke, but there
 /  / _ , __o  ____  he was, lying on the deck, flat as a mackerel - kelpless!"
/  (_</_\/ <__/ / <_	These are NOT AT&T's opinions; let them make their own.