Xref: utzoo comp.lang.c++:3668 comp.lang.eiffel:275 Path: utzoo!utgpu!watmath!watdragon!rose!bamcpherson From: bamcpherson@rose.waterloo.edu (Brent McPherson) Newsgroups: comp.lang.c++,comp.lang.eiffel Subject: Re: Eiffel vs. C++ -- Let's drop the garbage collection arguments Message-ID: <14489@watdragon.waterloo.edu> Date: 14 Jun 89 23:55:51 GMT References: <6590148@hplsla.HP.COM> Sender: daemon@watdragon.waterloo.edu Reply-To: bamcpherson@rose.waterloo.edu (Brent McPherson) Organization: U. of Waterloo, Ontario Lines: 63 In article <6590148@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes: >> -C++ folks don't want to be FORCED to have garbage collection ALL the time. >> -Eiffel folks don't want to be FORCED to memory allocation ALL the time. >> >> The problem is, neither gets the choice. In C++, you CANNOT have garbage >> collection. In Eiffel you cannot PREVENT garbage collection. Why not >> give the programmer a choice? Wrong, Eiffel allows the user to turn GC on/off. > >Perhaps a harder [impossible?] problem is to create a GC that is easily >portable to the wide variety of machines that C++ supports. More modern >GCs tend to get involved with the virtual memory hardware in order to speed >the scan for garbage. Clearly these kinds of approaches are hard to port >between machines. > It seems to me that GC in a language such as Eiffel is alot easier to implement since there is no notion of a global variable. The program starts at the root class and all active objects are objects that can be reached from the root class. This is a simple tree structure (and hence easier to traverse). > >Still, it would seem to be useful to have some kind of GC available for C++, >if only to report on objects that programmers have lost track of. Most people seem to have a rather narrow view of what garbage collection should be used for. It is not to free objects that programmers "lose track of". In the hands of a competant programmer GC is a powerful tool. Data structures can become more compact since different objects may safely point to the same data. In C (and other languages with no garbage collection) there is usually one reference per structure. If the same data is needed in another structure then a new copy is made. This allows memory to be released easily but is wasteful and slow. One way in which I have used GC is to keep a fixed-size list of object references (stored in Least Recently Used order). Objects is this list could share common sub-structures with other objects in the system. When the list became full, the Least Recently Used object would drop off (be removed) from the list. If the object or its components are no longer referenced by other active objects in the system, they then become candidates for GC. This is a very easy way to keep a history list of objects to avoid unecessary computation/disk access for frequently used objects. A program designed in this fashion will often outperform a similar and more complicated C program (since it is a *smarter* program). Conclusion: Both GC and explicit free are useful. Structures that are created/destroyed in a systematic manner are good candidates for the latter scheme since the programmer knows when an object is no longer referenced and may be freed. In complicated cases programmers tend to make mistakes (ei. free used memory or create dangling references). In these cases GC is the better choice. A wise programmer will use all tools at their disposal to obtain the best solution to a given problem. -- Brent McPherson bamcpherson@rose.waterloo.edu