cline@sun.soe.clarkson.edu (Marshall Cline) (06/10/89)
In article <1021@krafla.rhi.hi.is> snorri@rhi.hi.is (Snorri Agnarsson) writes: >From article <77300029@p.cs.uiuc.edu>, by johnson@p.cs.uiuc.edu (Ralph Johnson): >>>Written 6:48 pm Jun 4, 1989 by bertrand@eiffel.com (Bertrand Meyers): >>>Garbage collection >> This is both a major advantage and disadvantage. Would you advise >> us writing our operating system in Eiffel instead of C++? What >> impact does your garbage collector have on real-time software? >In my opinion garbage collection is the single most useful feature >of a programming language..... >.... Consider the following C function: [...deleted...] >If C had garbage collection we could write code such as: [...deleted...] >Instead we have to write as follows: [...deleted...] I'm going to *TRY* not to take sides in the war over the value of GC. I **AM** going to say that the line of thinking is getting *OUT*OF*HAND*!! The original poster (Bertrand Meyers) said he liked GC for such-in-such a problem. The respondent (Ralph Johnson) said real-time software wasn't suited for GC. Now we get Snorri Agnarsson saying that he can come up with an example where GC is useful. WAKE UP FOLKS! GC *IS* a useful feature *SOMETIMES*. It *MAY* not be a useful feature *ALL* the time! The argument is getting WAY off course. It's simply not true that: "Language X is better than Y *ALL* the time because it has feature Z which is useful *SOME* of the time". >It is often said that garbage collection is too costly, but I suggest >that in the above example the solution with garbage collection is >probably more efficient, both in programmer effort AND in >the speed of the resulting program. By the way, if garbage collection >is too expensive, how about 'malloc' and 'free'? Do you think those >routines are less expensive? Why do you think so? No one in the C++ camp is saying that malloc()/free() are "free". The point is simply that malloc()/free() is ***CONTROLLABLE***. That's what C/C++ programmers like: TO BE IN CONTROL. That't what Eiffel programmers DON'T like: TO BE FORCED TO CONTROL. *NO* *NO* *NO* language is best under *ALL* *ALL* *ALL* circumstances. Any sufficiently experienced computer professional chooses the best tool to fit the job. 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. C++ folks like the machine to do exactly what/when they tell it to. Eiffel folks like a higher level of abstraction from the machine. Conclusion: Let's drop the garbage collection argument from this discussion. >>>Bertrand Meyer >> Ralph Johnson >Snorri Agnarsson Marshall Cline -- ________________________________________________________________ Dr. Marshall P. Cline ARPA: cline@sun.soe.clarkson.edu ECE Department UseNet: uunet!sun.soe.clarkson.edu!cline Clarkson University BitNet: BH0W@CLUTX Potsdam, NY 13676 AT&T: (315) 268-6591
campbell@redsox.bsw.com (Larry Campbell) (06/10/89)
In article <CLINE.89Jun9152152@sun.soe.clarkson.edu> cline@sun.soe.clarkson.edu (Marshall Cline) 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?
Contrast this with Modula-3, which provides GC, but makes it optional.
--
Larry Campbell The Boston Software Works, Inc.
campbell@bsw.com 120 Fulton Street
wjh12!redsox!campbell Boston, MA 02146marc@eiffel.UUCP (Jean-Marc Nerson) (06/11/89)
> ......... >No one in the C++ camp is saying that malloc()/free() are "free". >The point is simply that malloc()/free() is ***CONTROLLABLE***. >That's what C/C++ programmers like: TO BE IN CONTROL. >That't what Eiffel programmers DON'T like: TO BE FORCED TO CONTROL. > .......... > .......... >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. > .......... In Eiffel: 1) Object allocation is always under programmer's control since you know when you create a reference to an object. At execution time, the statement: obj.Create [Create could have possible arguments] does 1 or 2 things: o Call memory allocation routines of the run-time system. [where sbrk() is used instead of malloc()]. o Possibly execute the body of the Create procedure of the class obj is a instance of if it has been re-programmed with some initialization statements. The only case when memory allocation is not under programmer's control is for the creation of the first object of the system, instance of the root (or main) class. One could imagine an application consisting of only one single class with no object creation at all except for the root object. This is not an O-O programming style ... 2) Garbage collection can be under programmer's control. o Garbage collection is a compilation option. o If the system is compiled and linked with the garbage collector, the default mechanism is quasi parallel and self adaptive. There is also a way for the application to control it by inheriting from a library class called MEMORY that provides operations to turn it on and off or even to do a 'Lisp-like' full collection if wanted. ------------------------------------------------------ Jean-Marc Nerson -- Interactive Software Engineering marc@eiffel.com
sommar@enea.se (Erland Sommarskog) (06/12/89)
Larry Campbell (campbell@redsox.UUCP) writes: >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? I don't have my OOSC around at the moment, but far as I recall Eiffel does give you a choice. You can turn off garbage collection if you absolutely have to. And calls corresponding to manually free memory are also available. But you are certainly not encouraged to use them. My apologies if I'm wrong on this point. I don't speak C++, but an object-oriented langauge without garbage collection seem quite useless to me. Or rather: it's not really an object-oriented langauge, just a more structured form of C. -- Erland Sommarskog - ENEA Data, Stockholm - sommar@enea.se Bowlers on strike!
marti@ethz.UUCP (Robert Marti) (06/12/89)
In article <778@redsox.bsw.com>, campbell@redsox.bsw.com (Larry Campbell) writes: > In C++, you CANNOT have garbage collection. Wrong. You can redefine operator new to use a garbage collecting allocator, for example the one written by Hans-Juergen Boehm and Alan Demers, which is described in H.-J. Boehm, M. Weiser: Garbage Collection in an Uncooperative Environment. Software Practice & Experience, Sept. 1988, pp.807-820. and available from the archive server at RICE University. In release 2.0, you can even redefine operator new on a class per class basis. -- Robert Marti Phone: +41 1 256 52 36 Institut fur Informationssysteme ETH-Zentrum CSNET/ARPA: marti%inf.ethz.ch@relay.cs.net CH-8092 Zurich, Switzerland UUCP: ...uunet!mcvax!ethz!marti
jima@hplsla.HP.COM (Jim Adcock) (06/13/89)
> -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.
snorri@rhi.hi.is (Snorri Agnarsson) (06/13/89)
From article <CLINE.89Jun9152152@sun.soe.clarkson.edu>, by cline@sun.soe.clarkson.edu (Marshall Cline): > No one in the C++ camp is saying that malloc()/free() are "free". > The point is simply that malloc()/free() is ***CONTROLLABLE***. You seem to be suggesting that malloc()/free() is more controllable than malloc()/garbage collection. If so, then in what sense?? Garbage collection can be time-consuming, of course, but so can free(). If you have a language with garbage collection, it is usually very easy to ensure that no garbage collection gets performed in some critical section by simply not allocating any memory. > That's what C/C++ programmers like: TO BE IN CONTROL. > That't what Eiffel programmers DON'T like: TO BE FORCED TO CONTROL. I do not understand what you are trying to say. > C++ folks don't want to be FORCED to have garbage collection ALL the time. That's good since in most instances they don't have garbage collection any of the time. But maybe some of them would like to have garbage collection some of the time. > Eiffel folks don't want to be FORCED to memory allocation ALL the time. ???????????? > Conclusion: Let's drop the garbage collection argument from this discussion. If you think talking about garbage collection is a waste of bandwidth you are certainly entitled to that opinion, but I do not have to agree with you. > Marshall Cline -- Snorri Agnarsson | Internet: snorri@rhi.hi.is Taeknigardur, Dunhaga 5 | UUCP: ..!mcvax!hafro!rhi!snorri IS-107 Reykjavik, ICELAND
jima@hplsla.HP.COM (Jim Adcock) (06/15/89)
> In article <9438@alice.UUCP> bs@alice.UUCP (Bjarne Stroustrup) writes: > =Bertrand Meyer, president of Interactive Software Engineering, the > =supplier of Eiffel, is correct on one point: I did refuse to appear on > =a panel with him. My reasons are personal. He has insulted my friends > > This is censorship and this sucks. I would have kicked you off the panel. > Am I the only one who finds this behavior reprehensible? The panel chair > who withdrew his offer to Dr. Meyer gets an F for bad judgement too. All this ill-will and name calling sucks. *I* certainly wouldn't want to be on a panel if I was afraid it was going to degrade into a pissing match. Let's leave that to the experts -- Congress.
bamcpherson@rose.waterloo.edu (Brent McPherson) (06/15/89)
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
jima@hplsla.HP.COM (Jim Adcock) (06/23/89)
> 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. > 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. (false.) Since Boehm's GC is designed to be portable, and has been ported to many different machine, there is at least one "public domain" GC that you can take with you when you move to a new machine. Ideally, write portable C++ code using G++ or cfront and Boehm's GC, and you should be able to port transparently to just about any machine you choose. > (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.) Warts are in the eye's of the beholder. In my opinion, forcing users of a language to use one particular GC scheme, where no particular GC scheme is universally applicable, is a wart, since this destroys a language for many of its would-be users. C++ attempts to leave as many of these decisions as possible in the hands of its users. Thus I am not force to use one person's idea of what I/O should look like. Nor am I forced to use one person's GC scheme.
bs@alice.UUCP (Bjarne Stroustrup) (06/23/89)
There is an important question that needs to be asked in regards to GC of C++ programs: ``When an object is garbage collected should its destructor (if any) be called?'' People often simply assume that the answer is `yes.' This is not obvious. Consider GC as simply a relatively cheap way of achieving an infinite memory. If we had a genuine infinite memory and used `new' and `delete' the constructors for objects allocated using `new' and not deleted would not be called (as C++ is currently defined). In other words, it would still be the programmer's task to call `delete' to trigger the destructor even if memory usage was of no concern. 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. The former is more `manual' and more predictable in terms of when things happen. The latter more automatic and (I think) imposes the rule that every object on the free store must be destroyed on normal program termination. I suspect that the programming of destructors will differ significantly dependent on the model adopted.
shopiro@alice.UUCP (Jonathan Shopiro) (06/23/89)
In article <9522@alice.UUCP>, bs@alice.UUCP (Bjarne Stroustrup) writes: > There are 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. > > The former is more `manual' and more predictable in terms of when things > happen. The latter more automatic and (I think) imposes the rule that every > object on the free store must be destroyed on normal program termination. This seems backwards. If the semantics of your class requires that every object which is created be destroyed before program termination, then objects that remain in the free store at program termination must be destroyed and objects that are reclaimed by GC must also be destroyed. [The former can be arranged pretty easily by chaining all objects of the class together and appointing a static object (of another class) to destroy anything left on the chain when it is destroyed.] If the semantics of the class allows objects to be simply abandoned when they will no longer be used then they can be left in the free store when the program terminates and GC can recycle the object's memory when the object is inaccessible. An example of a class whose semnantics require that every object be destroyed is a file class where the destructor flushes an internal buffer, and an example of a class whose semantics allow objects to be abandoned is a list whose destructor deletes the elements of the list. The `automatic destruction' model is suitable for both kinds of classes. If you have an `infinite memory' model GC and you have a class whose objects cannot be simply abandoned, you must be sure not to lose any of them. I actually don't think this is a very heavy requirement, because (I think) such classes are not very common, and when they are used, not many instances are created. The heavy requirement is, as usual, you have to know what you are doing. -- Jonathan Shopiro AT&T Bell Laboratories, Warren, NJ 07060-0908 research!shopiro (201) 580-4229
nevin1@cbnewsc.ATT.COM (nevin.j.liber) (06/24/89)
In article <34@enea.se> sommar@enea.se (Erland Sommarskog) writes: >I don't have my OOSC around at the moment, but far as I recall Eiffel >does give you a choice. You can turn off garbage collection if you >absolutely have to. But doesn't this affect class (or whatever the equivalent of "class" is in Eiffel) design? I, for would, would design differently based on whether there was GC or not. Is this done globally or on a class-by-class basis? There are problems with either approach. If it is global, some classes may die because there is nothing reclaiming memory. If it is on a class-by-class basis, I have to avoid all classes which might possibly use GC, or it really isn't "turned off" for my class. -- NEVIN ":-)" LIBER AT&T Bell Laboratories nevin1@ihlpb.ATT.COM (312) 979-4751
nevin1@cbnewsc.ATT.COM (nevin.j.liber) (06/24/89)
In article <1026@krafla.rhi.hi.is> snorri@rhi.hi.is (Snorri Agnarsson) writes: |You seem to be suggesting that malloc()/free() is more controllable than |malloc()/garbage collection. If so, then in what sense?? |Garbage collection can be time-consuming, of course, but so can free(). But free() is more predictable. In many current schemes, you never know exactly when GC will take place, or how long it will take. |If you have a language with garbage collection, it is usually very easy |to ensure that no garbage collection gets performed in some critical |section by simply not allocating any memory. What if I *need* to allocate memory in a critical section? Stopping GC for some-of-the-time is not a trivial issue. -- NEVIN ":-)" LIBER AT&T Bell Laboratories nevin1@ihlpb.ATT.COM (312) 979-4751
campbell@redsox.bsw.com (Larry Campbell) (06/25/89)
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.
--
Larry Campbell The Boston Software Works, Inc.
campbell@bsw.com 120 Fulton Street
wjh12!redsox!campbell Boston, MA 02146diamond@diamond.csl.sony.junet (Norman Diamond) (06/26/89)
In article <9522@alice.UUCP> bs@alice.UUCP (c++.God) writes: >There is an important question that needs to be asked in regards to GC >of C++ programs: > ``When an object is garbage collected should its destructor > (if any) be called?'' Perhaps an alternative destructor should be called. Perhaps its name could be !classname(). The reason for an alternative destructor is that the user might not have expected "leaks" but wishes to be prepared to do debugging. If a user expects garbage collection as normal for a class, then !classname() might invoke ~classname(), uh, er, or they might both invoke the same "helper" routine. -- Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.jp@relay.cs.net) The above opinions are claimed by your machine's init process (pid 1), after being disowned and orphaned. However, if you see this at Waterloo, Stanford, or Anterior, then their administrators must have approved of these opinions.
jima@hplsla.HP.COM (Jim Adcock) (06/27/89)
> 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.
jima@hplsla.HP.COM (Jim Adcock) (06/29/89)
> / 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.
jima@hplsla.HP.COM (Jim Adcock) (06/30/89)
> What if I *need* to allocate memory in a critical section? Stopping GC > for some-of-the-time is not a trivial issue. Depends on the design goals of the GC. Traditionally GCs were invoked when one "runs out of memory." Turning off GC in this scenerio doesn't help one do critical paths, if one still needs memory. Boehm's GC has the easier -- and on virtual memory machines -- the more reasonable goal of reducing the growth of heap space. So one can "always" turn off GC for a while -- it just means heap might grow on you. If your critical path can't afford to wait while the O.S. grows heap space, then you can explicitely grow heap space before entering your critical region. Still, one needs a programming task that can afford several seconds time out occasionally. Strict "real-time" systems may not be able to handle this.
paul@moncam.co.uk (Paul Hudson) (07/10/89)
Has anyone contributing to this thread *read* the subject? All the discussion seems to be *about* the GC arguments ;=) All together now: "Let's drop ... " (Yes, I know, this is a dreadful waste of the net bandwidth). -- Paul Hudson MAIL: Monotype ADG, Science Park, Cambridge, CB4 4FQ, UK. PHONE: +44 (223) 420018 EMAIL: paul@moncam.co.uk, ;" FAX: +44 (223) 420911 ...!ukc!acorn!moncam!paul `"";";" "/dev/null full: please empty the bit bucket"
mo@prisma (07/10/89)
Re Garbage Collection: An ounce of garbage prevention is worth pounds and pounds of garbage collection. If you design with garbage management in mind, you discover you don't really miss a GC. On the contrary, I've seen lots of programs that work only BECAUSE the GC lets dangling pointers continue to work. This is actually quite humorous - the LISP folks have discovered that after they get their algorithms right, if they rewrite their inference grinders in C with good garbage prevetion and management, they get dramatic speed improvements. And here we have the C folks going the other way. Isn't life strange....
campbell@redsox.bsw.com (Larry Campbell) (07/22/89)
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
chase@Ozona.orc.olivetti.com (David Chase) (08/03/89)
In article <779@redsox.bsw.com> campbell@redsox.UUCP (Larry Campbell) writes: >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. To be fair, this is only somewhat the case. In code that is explicitly declared as UNSAFE you are allowed to choose on a type-by-type basis whether or not objects are GC'd or not. In practice, most code should *not* be unsafe (though some very important code will be unsafe), and writing unsafe code places a much greater burden on the programmer. It really isn't much different from writing C, except that many more errors become the fault of the programmer, and the run-time system is not really tuned to make life easy for the author of unsafe code. For example, if you store a pointer to garbage-collected memory in a record field that is declared to be an INTEGER, the memory could be reused. That's a programmer error. If you store a pointer to gc memory at an unapproved offset (i.e., odd byte alignment), the memory could be reused. That's a programmer error. If you write unsafe code, then it is presumed (as so many C programmers are quick to claim) that you know what you are doing. David
nadkarni@ashok.dec.com (08/03/89)
In article <45901@oliveb.olivetti.com>, chase@Ozona.orc.olivetti.com (David Chase) writes... >In article <779@redsox.bsw.com> campbell@redsox.UUCP (Larry Campbell) writes: >>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. > >To be fair, this is only somewhat the case. In code that is >explicitly declared as UNSAFE you are allowed to choose on a >type-by-type basis whether or not objects are GC'd or not. In > > [stuff deleted] >David Not true as far as I recall. If I remember the report correctly, you CAN decide on a type by type basis whether to GC or not. The UNTRACED keyword is provided for this purpose. This is true even for SAFE modules. What you might be referring to is that untraced REFs can point to traced REFs (or is it the other way around ?) only in UNSAFE modules. Of course, I've done little more than glance through the language definition so I might be wrong. /Ashok