home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / compiler / 1364 < prev    next >
Encoding:
Internet Message Format  |  1992-08-13  |  2.0 KB
  1. Path: sparky!uunet!cs.utexas.edu!uwm.edu!linac!att!rutgers!faatcrl!iecc!compilers-sender
  2. From: mw@ki.fht-mannheim.de (Marc Wachowitz)
  3. Newsgroups: comp.compilers
  4. Subject: Re: Adding garbage collection to C++
  5. Keywords: C, GC
  6. Message-ID: <92-08-063@comp.compilers>
  7. Date: 13 Aug 92 11:40:23 GMT
  8. References: <92-08-052@comp.compilers>
  9. Sender: compilers-sender@iecc.cambridge.ma.us
  10. Reply-To: mw@ki.fht-mannheim.de (Marc Wachowitz)
  11. Organization: Fachhochschule fuer Technik Mannheim
  12. Lines: 30
  13. Approved: compilers@iecc.cambridge.ma.us
  14.  
  15. Thomas M. Breuel <tmb@arolla.idiap.ch> wrote:
  16. : As far as I can tell, ANSI-C and C++ are both fully garbage collectable
  17. : within the current language standard.
  18.  
  19. At least you would have to be very careful when the programmer copies the
  20. value of the last pointer to some heap object to some memory region (e.g.
  21. an unsigned char[]) and changes the order of the array elements, then
  22. destroys the pointer.  No more live reference is detectable by the
  23. collector, but the programmer may copy back the pointer value (again
  24. changing the byte order) and ... :-) I guess such manipulations would be
  25. possible with the current standard.
  26.  
  27. : More precisely, I believe that you could compile ANSI-C to portable and
  28. : idiomatic CommonLisp (the main difficulty is pointers to automatic
  29. : variables).
  30.  
  31. I'm not sure whether C would allow changing addresses; if not, you'd have
  32. to translate them into something else if your Lisp implementation uses a
  33. moving collector, which is quite likely. This is surely possible, but
  34. hardly very efficient - so why not use Lisp in the first place, with
  35. better performance :-)
  36. --
  37. Marc Wachowitz
  38. mw@gandalf.ki.fht-mannheim.de, 75742@novell1.rz.fht-mannheim.de
  39. [It is my impression that an ANSI C program is allowed to copy a pointer to
  40. a long and later back to a pointer of the same type.  This sort of thing
  41. makes it hard to find all the live data. -John]
  42. -- 
  43. Send compilers articles to compilers@iecc.cambridge.ma.us or
  44. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  45.