Xref: utzoo comp.lang.c++:4229 comp.lang.eiffel:339 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!rochester!rit!tropix!moscom!ur-valhalla!uhura.cc.rochester.edu!sunybcs!rutgers!apple!bloom-beacon!husc6!redsox!campbell From: campbell@redsox.bsw.com (Larry Campbell) Newsgroups: comp.lang.c++,comp.lang.eiffel Subject: Re: Eiffel vs. C++ -- Let's drop the garbage collection arguments Message-ID: <779@redsox.bsw.com> Date: 22 Jul 89 12:30:45 GMT References: <6590148@hplsla.HP.COM> <14489@watdragon.waterloo.edu> Reply-To: campbell@redsox.UUCP (Larry Campbell) Organization: The Boston Software Works, Inc. Lines: 22 Apparently I was too terse for my own good. When I said (simplistically) that "C++ prevents GC and Eiffel mandates it", people jumped all over that statement, insisting that you can graft GC onto C++ and you can turn GC off in Eiffel. 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; I've even seen GC grafted onto plain old C. In my opinion, this doesn't count; since there's no language support, if you expect to use it, you're nonportable. (I haven't seen the C++ GC wart, but the C one required assembly language and an intimate knowledge of stack frames and register contents.) And while Eiffel apparently lets you temporarily disable and enable GC on a global basis, this is not a very fine grain of control. Modula-3, by contrast, allows you to decide on a type-by-type basis whether objects of the type are to be GC'd or not. This seems to me to be the best solution. -- Larry Campbell The Boston Software Works, Inc. campbell@bsw.com 120 Fulton Street wjh12!redsox!campbell Boston, MA 02146