Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!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: <6590172@hplsla.HP.COM> Date: 28 Jun 89 17:34:59 GMT References: Organization: HP Lake Stevens, WA Lines: 26 > / hplsla:comp.lang.c++ / campbell@redsox.bsw.com (Larry Campbell) / 7:53 pm Jun 24, 1989 / > In article <6590166@hplsla.HP.COM> jima@hplsla.HP.COM (Jim Adcock) writes: > -> What I should have said is that "there is no language support for GC in C++" > -> (true) even though by suitable hackery you can graft it in; > - > -(false.) Overloading "new" and "delete" constitute C++ support for GC in > -my opinion, since I can now attach the GC scheme of my choice where I want > -it when I want it. Either as a global decision, or on a class by class basis. > > Nope. How do you find the garbage? Overloading new() and delete() won't > find garbage for you. I can easily lose a pointer to an object without > calling delete() on it. Yep. ::Delete only gets used if the user doesn't lose an object, and/or explicetely deletes it. Otherwise the GC finds and deletes lost objects. In my example ::new calls Boehm's gc_alloc and ::delete calls Boehm's gc_free, with essentially the same meanings as the standard C malloc and free, except that at "appropriate" times gc_alloc calls the GC or increases heap space based on a heuristic algorithm. I believe gc_free returns an object to free space, maybe makes some marks, and updates the statistics gc_alloc uses to determine when to increase heap space or garbage collect. My overloading ::delete was just another example of the general rule that whenever one overloads a new, one should overload the matching delete. This is independent of whether one is losing objects or not, or whether one is using a GC. Sorry I didn't make this more clear.