Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-pcd!hplsla!jima From: jima@hplsla.HP.COM (Jim Adcock) Newsgroups: comp.lang.c++ Subject: Re: Eiffel vs. C++ -- Let's drop the garbage collection arguments Message-ID: <6590171@hplsla.HP.COM> Date: 26 Jun 89 18:22:21 GMT References: Organization: HP Lake Stevens, WA Lines: 34 > There is therefore two possible models for garbage collection of C++: > > (1) the `infinite memory' model where destructors are only called > for explicitly deleted objects, and > (2) the `automatic destruction' model where destructors are called > where the memory used to store objects are recycled. > Seems to me the two models can, and maybe must, coexists. Seems like to get a destructor called when a lost object is found, one would want to have a virtual destructor. To know that an object has a destructor, and where in the vtable the destructor is, the GC is going to need some info about a class of an object. Which is going to require some cooperation between a class and a GC. A simple "solution" is to have objects who need to have destructors called when found be derived from some gc_base_class, where gc_base_class objects can be identified as such by the GC, and have a destructor protocol understood by the GC. Lacking this knowledge about an object, the GC wouldn't know enough to be able to call a destructor [if one exists.] Certainly there are other ways of doing this, that wouldn't need vtable pointers -- for example objects of a certain type could be allocated from pools, where the type of the pool is known to the GC. This still requires cooperation from the GC. Anyway, classes thus fall naturally into two categories -- those that cooperate with a GC, and those that don't. If you want your class to have destructors called by a GC, it will have to cooperate with that GC, otherwise no destructors will be called. It would be nice if people who are writing GCs write them in such a way that they can coexist with other memory managers [Boehm's claims this capability.] Then a choice of GC could be considered part of a class writer's design decisions. A GC that locks out other GCs then would be considered a bad design.