Newsgroups: alt.lang.design,comp.lang.c++,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!nntp.club.cc.cmu.edu!hudson.lm.com!news.pop.psu.edu!news.cac.psu.edu!howland.reston.ans.net!ix.netcom.com!netcom.com!nagle
From: nagle@netcom.com (John Nagle)
Subject: Re: Comparing productivity: LisP against C++ (was Re: Reference Counting)
Message-ID: <nagleD1tGnr.LEu@netcom.com>
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: <D16Ho3.4BE@lcpd2.SanDiegoCA.NCR.COM> <3e2bj6$43a@network.ucsd.edu> <3e30ag$ar1@wariat.wariat.org> <19941231.180912.4252 <19950102.201947.114496.NETNEWS@UICVM.UIC.EDU>
Date: Tue, 3 Jan 1995 06:28:39 GMT
Lines: 38
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:105631 comp.lang.lisp:16247

dhanley@matisse.eecs.uic.edu (David Hanley) writes:
>John Ellis (ellis@parc.xerox.com) wrote:
>: I suggest you read the literature on conservative collection.  Start
>: with the references in "Safe, Efficient Garbage Collection for C++"
>: (ftp://ftp.parc.xerox.com/pub/ellis/gc).

>        You know it's simply _INCREDIBLE_ to me how ignorant the
>GC/LISP crowd is coming across.  I have the paper, read it, and even
>tested it out a bit.  I think it's a good idea( though hardly new ) to
>keep seperate heaps.  But I don't at all care for the restrictions
>placed on C++ in the paper.  I like me Boehm's approach better, and he
>seems much more objective about GC ( not to mention more intelligent )
>than many of the supporters of GC.

      1.  Ellis's work uses Boehm's garbage collector.  John Ellis and
	  Hans Boehm both work at Xerox PARC, in the same building.

      2.  What restrictions on pointer manipulation don't you like?
          The Detlefs/Ellis/Boehm work allows pointer arithmetic,
          pointers into the middle of objects, pointers one off the
          end of objects, pointers coerced to "wrong" pointer types,
          pointers to on-stack objects, even mixed GC and non-GC pointers.
          There are few things you can do to a pointer that will break
          a Boehm-type GC that are valid C++ according to the ARM.
          See ARM 5.7 and 5.7.  Pointer to integer conversion is
	  discouraged, may be nonportable, and arithmetic on a pointer
          converted to an integer may produce nonportable results.
          (Especially on 16-bit Intel hardware)  It is illegal to
	  do pointer arithmetic which results in a pointer off the
	  end of an object by more than one element. (ARM 5.7).
	  The C++ spec is much more restrictive than the C spec in
	  this regard. 

          What do you want to do that the Ellis/Detlefs approach
	  won't let you do?

					John Nagle

