Re: Strong/weak pointers

"Armel" <armelasselin@hotmail.com>
Wed, 3 Sep 2008 12:24:05 +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)
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: "Armel" <armelasselin@hotmail.com>
Newsgroups: comp.compilers
Date: Wed, 3 Sep 2008 12:24:05 +0200
Organization: les newsgroups par Orange
References: 08-09-004
Keywords: storage, design
Posted-Date: 03 Sep 2008 06:26:54 EDT

"Michiel Helvensteijn" <m.helvensteijn@gmail.com> a icrit dans le message de
> [...]
>
> 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).


Regarding your cycles problem, double reference counting was chosen for
COM/OLE of MS (in this solution "outside of cycles" pointers, such as
pointers which are on stack, global or in 'client' code, are "stronger" than
the internal pointers, reaching zero-count on the stronger provoque
auto-cleaning which in turn leads the internal pointers count to 0, finally
destroying the obejct)


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


[Let's call the object poitned to by a weak pointer a WP object]


My opinion on this is that weak pointers are extremely useful, they serve in
all the cases were you want to "inform" (your object publishes information
toward some another WP object, and you clearly do not want prevention of
destruction of WP object just because the source of event is still alive) or
you want to "look at" (in this case, you just want to know if an object
still exists... so _only_ a weak pointer can do this job).


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


If the parameter or return is not itself a weak pointer, the passed in/out
weak pointer need to be upgraded to a strong pointer first. this is simply
the opposite of what you may find 'normal', that is, setting a strong
pointer into a weak pointer.


HIH
Armel



Post a followup to this message

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