Strong/weak pointers

This is a discussion on Strong/weak pointers within the Compilers forums in Theory and Concepts category; Torben Fgidius Mogensen wrote: > Michiel Helvensteijn <m.helvensteijn @ gmail.com> 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 ...

Go Back   Application Development Forum > Theory and Concepts > Compilers

Object Mix

Register FAQ Calendar Search Today's Posts Mark Forums Read
  #11  
Old 09-06-2008, 02:58 PM
GPS
Guest
 
Default Re: Strong/weak pointers

Torben Fgidius Mogensen wrote:
> Michiel Helvensteijn <m.helvensteijn@gmail.com> 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
>> course).

>
> 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
constraints.

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?


George
[The last time I checked, the ACM only charged $5 per article if you
don't have a site license. -John]
Reply With Quote
Reply


Thread Tools
Display Modes


All times are GMT -5. The time now is 06:06 AM.


Powered by vBulletin® Version 3.7.2
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.2.0
vB Ad Management by =RedTyger=

In an effort to better serve ads to our visitors, cookies are used on objectmix.com. For more information, check out our Privacy Policy.