Subj : Re: OO compilers and efficiency
To   : comp.programming
From : Rob Thorpe
Date : Sat Jul 23 2005 05:30 am

Flavius Vespasianus wrote:
> "Ed Prochak" <ed.prochak@magicinterface.com> wrote in
> news:1122051641.933727.255340@g44g2000cwa.googlegroups.com:
>
> > I for one thought that GC was a stupid idea. It makes the OO
> > programmers lazy.
>
> Notice the path we have gone on.
>
> - C was completely and totally FOXTROT UNIFORMED when it came to arrays and
> strings.
> - Because of this, C programmers had to make excessive use of direct
> dynamic memory calls.

A more polite way to say this would be to say that C does not support
dynamic strings or arrays, so the programmer must write functions to do
these things usually using malloc/free calls.

> - In order to maintain compatibility with C, C++ mimics this.

Not really.  The creators of C++ could have just added dynamic strings
and arrays - which in fact they did.  Allocation with new/delete was
added because dynamic allocation is useful anyway.  Even if strings and
arrays can be variably sized the availability of heap memory is very
useful for other more complex data-structures such as tree and
hash-tables.

> - Dynamic memory is a problem in programming so people find the need to
> create programming languages based upon C++ with GC.
>
> In general, programmers should program to clean up what the create

Programmers can as you say write to clean up what they create.  But in
many circumstances the question is: why should they?  It's often a very
complex task, in particular in object-orientated programs.

For example:
In OO programs it's common to have the destructor of one object destroy
other objects that it has allocated, which in turn destroy objects they
have allocated.  This can be very difficult to code if some of these
destructors require information from some of the objects above them to
know how they should be destroyed or destroy other things.  So the
programmer must carefully create a precise order of destruction running
through the program.

> but C
> forced you to create with unnecessary abandon.
>
> Yeh, for SIMPLE things GC might be better for inexperienced programmers who
> are likely to screw up free/malloc, new/delete. For more complicated
> applications, GC is most often inappropriate.

GC is certainly useful for inexperienced programmers.  It's also useful
for simple scripts where you don't care about things like performance.

> For more complicated applications, GC is most often inappropriate.

I think large applications are where GC is more useful.  Programs that
have large amounts of code tied to them generally fall into two
categories, either 1) a few small parts of the code determines the
run-time or 2) large parts of the program determines the run-time.
In case #1 GC can be used to save programming time.  In the critical
parts GC need not be used if it's slow.
Case #2 is a program with no defined hot-spots, these tend to suck in
terms of performance anyway because they're difficult to optimize.  In
this case little is lost by using GC.

The area of programming where there is a good argument not to use GC is
in programs that are bigger than the disposable scripts I mentioned
above, but not large enough to use heap memory in difficult ways.

> Some day, if I have the time, I'd like to run tests on Java's garbage
> collector. Does anyone know if it can handle lost cyclic graphs? (Many GCs
> can't).

Yes, a JVM's garbage collector must be proof against cyclic graphs.
Fortunately, that's not hard, copying/moving collectors and mark-sweep
collectors both are.

.