|[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 firstname.lastname@example.org (Marco van de Voort) (2008-09-02)|
|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:||Wed, 3 Sep 2008 22:33:38 -0700 (PDT)|
|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
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.
Return to the
Search the comp.compilers archives again.