[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Oct 8 12:14:04 1993 
Subject:Re: Threaded Interpretive Languages 
From:John Q. Mitchell 
Volume-ID:931010.01 

In article <2330@ulogic.uucp>, Richard M. Hartman <hartman@ulogic.UUCP> wrote:
>I have yet to be convinced that garbage collection is a requirement
>for efficient programming.  I have never found it difficult to decide
>when I am done with an object and free() it.  Perhaps if you could
>describe a situation where automatic GC is a requirement, and not merely 
>a convenience it would help me to understand.
>
>Until then, phrases like "knowing that he does not have to worry
>about reclaiming them" merely imply (to me) a lazy develper who 
>cannot be bothered to figure out when he is done playing with 
>his "toys".  This is NOT meant as a slight to Mr. Knight -- merely
>the biased viewpoint of someone who has been malloc()ing & free()ing
>for over a decade with very few difficulties who would like to know
>just what GC can buy me.

I've heard heard wonderful things about automatic GC (less hassle,
actualy more efficient, etc), but am also unimpressed.

Mr. Knight, from your statement above, I conclude that I am a lazy
developer who has problems putting away my toys.  Although I use
malloc/free on a daily basis, and have been for years, I still get the
jitters using them.  Free the wrong thing and you're toast.  Worse yet,
I get core dumps on malloc() because I overwrote a memory array
SOMEWHERE in the program.  Ugh!  Proper use of malloc/free require more
paitience and attention to detail that I can muster, sometimes.

Yes, I know that in order to solve the problem I need careful
forethought, planning, etc.  However, in my job where speed of
code-writing is more important than generality or good "style",
malloc/free has bitten me more than a few times.  However, I've found an
answer:

Dont use malloc/free.  When at all possible, write the application in
C++, which doesnt have automatic GC, but allows easy, fast, and relatively 
clean memory control.  Most of the time, C++ handles the
allocation/destruction transparently for you.  Even when explicit memory
calls are required, it's generally a no-brainer to add a statement or
two to a classes' instatiation/destruction functions.

In short, why wait for garbage collection?  Why mess with error-prone
malloc/free?  Just use C++!  Concentrate on the application, not on
minor details that can nail you later.


							- john