Re: Strong/weak pointers

"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

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