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 +1.801.422.5771 /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
