|[4 earlier articles]|
|Re: Strong/weak pointers email@example.com (2008-09-02)|
|Re: Strong/weak pointers firstname.lastname@example.org (Dmitry A. Kazakov) (2008-09-02)|
|Re: Strong/weak pointers email@example.com (Armel) (2008-09-03)|
|Re: Strong/weak pointers firstname.lastname@example.org (glen herrmannsfeldt) (2008-09-03)|
|Re: Strong/weak pointers email@example.com (JW) (2008-09-03)|
|Re: Strong/weak pointers firstname.lastname@example.org (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2008-09-04)|
|Re: Strong/weak pointers email@example.com (GPS) (2008-09-06)|
|Date:||Sat, 6 Sep 2008 18:58:15 +0000 (UTC)|
|Keywords:||types, storage, comment|
|Posted-Date:||07 Sep 2008 17:34:23 EDT|
Torben Fgidius Mogensen wrote:
> Michiel Helvensteijn <firstname.lastname@example.org> writes:
>> My colleague and I are discussing the non-trivial problem of how the
>> pointers should behave in our new programming language. Most important
>> for us is that the pointers are 'safe'. That is, we wish to eliminate
>> dangling pointers and memory leaks. Even if this has a runtime and
>> memory penalty. Note that there is no pointer arithmetic in our
>> language, so it is also safe in that regard.
>> The hope is that a lot of the runtime penalties may be eliminated with
>> the help of our our theoretical proof system. But that's not what this
>> post is about.
>> Strong pointers (at least our version) behave as follows: You may set
>> a strong pointer to null, or make it point to an object. As long as at
>> least one strong pointer points to an object, the object will never be
>> destructed. So this effectively eliminates dangling pointers. To do
>> this we use a reference counter attached to the object.
>> We are aware of the fact that this does not completely eliminate
>> memory leaks, since the pointers can indirectly reference
>> themselves. We're not sure what to do about this. We may leave it to
>> the programmer to avoid. Or we may actually try to find isolated
>> cycles at any pointer de/re-allocation (but only in debug mode, of
> Why not use a better garbage collection method? Reference counting is
> slow and (as you say) does not handle cycles. A simple and reasonably
> fast GC is the two-space stop-and-copy. It can move objects around,
> so you should not allow comparison of pointers except for equality
> (i.e., avoid < and similar operators) and avoid casting integers to
> pointers and vice-versa.
Reference counting can handle cycles as I understand it, with certain
Daniel P. Friedman, and David S. Wise in 1979 wrote a paper titled:
_Reference counting can manage the circular environments of mutual
recursion_ That paper is referenced by Knuth in his TAOCP Volume 1
under Lists and Garbage Collection.
I've wanted to figure out the methods used in that paper for a while...
Unfortunately it seems you need an ACM account, or you have to purchase
the article from one of the 2 sources.
There may be something more recent available. Does anyone here know of
anything more recent?
[The last time I checked, the ACM only charged $5 per article if you
don't have a site license. -John]
Return to the
Search the comp.compilers archives again.