Re: Strong/weak pointers

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


CPython does it precisely this way.


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


Practically, cycles can't be avoided -- a node in DOM tree, for
example, would probably have links (pointers) to it's parent, siblings/
left-right-sibling and children. The gc module of Python finds such
cycles, and moves all inaccessible cycles into a global list. They are
_not_ destroyed automatically, since the runtime wouldn't know where
to break the cycle.


Weak pointers are a solution to this problem. For example, only parent-
child is a strong pointer, rest are all weak pointers. Links formed
using weak pointers do not form edges in the cycle.


> An important decision we've made is that every variable in the
> language IS a strong pointer. That is, there is no pointer*
> notation. Since an isolated strong pointer behaves just like a simple
> scoped variable, we thought it would be an elegant solution. Besides,
> this will make it easier to implement full closures and such when the
> time comes. To compensate, we have introduced the identity assignment
> operator (<-- as opposed to <-) and the identity comparison operators
> (==, !== as opposed to =, !=).
> What we're pondering is: should our language also feature weak
> pointers? A weak pointer cannot be the only pointer to an object
> (since an object requires at least one strong pointer reference to
> exist). And when an object is deallocated because of a lack of strong
> pointer references, all weak pointers referencing it become null. They
> WOULD need their own type notation.


Weak pointers can be simulated (at quite some runtime cost) by have a
"weakref" object that acually holds a strong pointer, and gets called
back when the pointee is deleted.


> While this may sound good, weak pointers bring all kinds of conceptual
> nightmares. Like, what should happen if we return a weak pointer from a
> function, or pass it to a function (with in, out or inout)?


Having a (first-class) "weakref" object solves this problem (assuming
your language has support for first-class objects).


> We would appreciate opinions on this. In particular, can you think of any
> good use-cases for weak pointers? Would it be a big loss if we left them
> out? Note that it is impossible to 'simulate' them with strong pointers, so
> it is an important issue.


Like the DOM tree example above. It is usually a common requirement to
have one object own another, and the second object having a link to
the first for navigation.


-JW.

Return to the comp.compilers page.
Search the comp.compilers archives again.