Cast not your Perl before swine?

Michael L Torrie torriem at
Tue Dec 18 11:35:33 MST 2007

Bryan Sant wrote:
> I see what you're saying.  Let's compare Java GC with a theoretical
> best-case malloc/free scenario to act as a baseline to help GC
> algorithms become even more efficient.  However, I believe that
> rewriting these apps in C/C++ would produce code that calls
> malloc/free far more often and thus is less efficient with its memory
> management that using a GC.

I've tried hard to keep silent on this issue, but this paragraph just
begs to be responded to.  You can believe what you want, but what is
true is another story.  Unless you can prove with a real world example
that your conjecture is correct (your example does not do this), your
assertion is merely something you wish to be true.  I get the impression
from your comments that you haven't written any large scale C++
applications, and don't have a whole lot of experience in the usual best
practices that C++ programmers user to explicitly manage resources.  You
also insist on saying "C/C++", which totally breaks your argument to
begin with, since they are different languages with different paradigms
including different mechanisms for resource allocation and destruction.
 C, for example, has no way of implicitly destroying data structures
other than structs.  C++, however, does.

C++ programmers typically rely on the scoping rules to help manage
resources.  (C++ on .NET is broken in this area.)  They do employ things
that Java also does (but did not invent) such as reference counting via
smart pointer objects.   For many short-lived objects, C++ programmers
don't bother to allocate them on the heap at all.  They are just
allocated extremely quickly right on the stack.  Java has no such
ability, and so *every* allocation *has* to be a heap allocation.  I'd
say in C++, at least 50% of all objects are allocated on the stack and
manipulated there, to be automatically destroyed when they go out of
scope.  Thus the explicit memory management issue isn't really as big a
deal as you make it out to be.

Even in Java, though, resource management needs to be in the
programmer's mind as he goes along.  On occasion, Java apps do in fact
leak, and can leak badly.  Or C# too.  The recent Darpa challenge
illustrated this.  When their computer ran out of memory because of a
reference leak, the vehicle could not function until the computer was
rebooted.  Eventually they discovered part of their program was hanging
onto references when they thought it had let them go.

Michael Torrie
Assistant CSR, System Administrator
Chemistry and Biochemistry Department
Brigham Young University
Provo, UT 84602

More information about the PLUG mailing list