Linked by Zachary Pinter on Tue 27th Apr 2004 17:09 UTC
General Development Garbage collection (GC) is a technology that frees programmers from the hassle of explicitly managing memory allocation for every object they create. Traditionally, the benefit of this automation has come at the cost of significant overhead. However, more efficient algorithms and techniques, coupled with the increased computational power of computers have made the overhead negligible for all but the most extreme situations.
Permalink for comment
To read all comments associated with this story, please click here.
@Solar
by Rayiner Hashem on Wed 28th Apr 2004 12:01 UTC

Traditionally, programmers coming from GC languages have a hard time to grasp the concept that, if you start to write destructors for every C++ class or have numerous "new()"s in your source, your design is broken. In over 90% of the cases, you have no need to use anything but automatic variables and default destructors.
This is true for the styles of programming common in C++. However, in lots of functional code, you need indefinite extent for objects, and GC is the only sane way to do it. Can you imagine trying to manually manage memory for closures?

Also, languages other than Java also have non-GC related cleanup methods available. It is very common for a Lisp or Dylan programmer to define a macro "with-open-file" (or whatever resource you want managed, and use it as such:

with-open-file (fs = "foo.text", element-type: <byte>)
read-to-end(fs)
end;

(Example stolen from fun-o's website ;)

This technique can be generalized to any resource you want, and can even be used to manage locks automatically:

with-held-lock(lock)
do-stuff();
end;

So the lack of determinite finalization really isn't a significant barrier to anyone except those coming from a C++ background ;)