Re: Strong/weak pointers

JW <james.williams1952@gmail.com>
Wed, 3 Sep 2008 22:33:38 -0700 (PDT)

          From comp.compilers

Related articles
[2 earlier articles]
Re: Strong/weak pointers Jan.Vorbrueggen@thomson.net (=?ISO-8859-15?Q?Jan_Vorbr=FCggen?=) (2008-09-02)
Re: Strong/weak pointers marcov@stack.nl (Marco van de Voort) (2008-09-02)
Re: Strong/weak pointers torbenm@pc-003.diku.dk (2008-09-02)
Re: Strong/weak pointers mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2008-09-02)
Re: Strong/weak pointers armelasselin@hotmail.com (Armel) (2008-09-03)
Re: Strong/weak pointers gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-09-03)
Re: Strong/weak pointers james.williams1952@gmail.com (JW) (2008-09-03)
Re: Strong/weak pointers lerno@dragonascendant.com (=?ISO-8859-1?Q?Christoffer_Lern=F6?=) (2008-09-04)
Re: Strong/weak pointers georgeps@xmission.com (GPS) (2008-09-06)
| List of all articles for this month |

From: JW <james.williams1952@gmail.com>
Newsgroups: comp.compilers
Date: Wed, 3 Sep 2008 22:33:38 -0700 (PDT)
Organization: Compilers Central
References: 08-09-004
Keywords: storage, design
Posted-Date: 05 Sep 2008 06:29:09 EDT

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



Post a followup to this message

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