Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!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: <6590148@hplsla.HP.COM> Date: 12 Jun 89 17:15:37 GMT References: Organization: HP Lake Stevens, WA Lines: 28 > -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? > > Contrast this with Modula-3, which provides GC, but makes it optional. Correct me if I'm wrong, but I can't think of anything in C++ that prohibits GC. It's just that no GC comes standard with C++. But then, not much in the way of libraries comes with C++. Certainly, there are a number of GC techniques that could be applicable to C++ -- its just hard to find a GC technique that would be close to universally applicable. 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. Also, GC tends to greatly limit how "real time" an application can be. So classes written using GC tend to be unusable in more demanding "real time" applications. So classes then get divided into two camps. Those using GC and those not using GC. 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.