Strong/weak pointers

Michiel Helvensteijn <m.helvensteijn@gmail.com>
Mon, 01 Sep 2008 15:12:14 +0200

          From comp.compilers

Related articles
Strong/weak pointers m.helvensteijn@gmail.com (Michiel Helvensteijn) (2008-09-01)
Re: Strong/weak pointers licaner@gmail.com (lican) (2008-09-01)
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)
[4 later articles]
| List of all articles for this month |

From: Michiel Helvensteijn <m.helvensteijn@gmail.com>
Newsgroups: comp.compilers
Date: Mon, 01 Sep 2008 15:12:14 +0200
Organization: Wanadoo
Keywords: storage, OOP, optimize
Posted-Date: 01 Sep 2008 17:27:12 EDT

Hi!


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


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 =, !=).


In most cases, it will be easy to eliminate the runtime cost of this
decision. If a variable is never used as a pointer, it can be
allocated on the stack.


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.


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


We're not sure, so we may leave weak pointers out of the language IF we
cannot find a convincing case for keeping them, and an elegant solution for
passing them around. Note that such a solution may be to eliminate our (in,
out, inout) parameter modifiers in favor of something like 'pass by value'
and 'pass by reference'.


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.


Thanks in advance for your reply!


--
Michiel Helvensteijn



Post a followup to this message

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