Linked by Zachary Pinter on Tue 27th Apr 2004 17:09 UTC
Permalink for comment
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/25/13 0:45 UTC
Linked by Thom Holwerda on 05/24/13 23:59 UTC
Linked by Thom Holwerda on 05/24/13 22:33 UTC
Linked by Howard Fosdick on 05/24/13 21:41 UTC
Linked by Thom Holwerda on 05/24/13 14:44 UTC
Linked by Thom Holwerda on 05/23/13 23:22 UTC
Linked by Thom Holwerda on 05/23/13 22:04 UTC
Linked by Thom Holwerda on 05/23/13 22:01 UTC
Linked by Thom Holwerda on 05/23/13 17:52 UTC
Linked by Thom Holwerda on 05/22/13 22:23 UTC
More News »
Sponsored Links



Any GC mechanism that depends on finalizers as the only object clean-up method trades an irritant with a real problem. The irritant is memory management. The problem is resource management --- semaphores, files and so on. One of the clean, effective and easy solution is to use constructors and destructors to manage the allocation and deallocation of these resources. This garanties proper deallocation at the proper time, without ever risking accessing deallocated or never-allocated objects. This idea is often nicknamed RAII (Resource Allocation Is Initialization). This technique cannot be used with finilizers, however, which may never be run (at all!)
This does not mean that GC is bad. C++ (which seems to survive everything, beats-me-how) now has several GC availble, including some very interesting "conservative" collectors, which garanties that destruction occurs exactly when the object goes out-of-scope. This is, IMHO, the way to go. This way, wrapper objects can be made which handles nearly resource management --- not just memory.
This is not about performance, though I admit that Java and .NET has problems in this regard. This is about correctness, which is far less easily solved.