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) |
From: | "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> |
Newsgroups: | comp.compilers |
Date: | Tue, 2 Sep 2008 19:20:28 +0200 |
Organization: | cbb software GmbH |
References: | 08-09-004 |
Keywords: | storage, design |
Posted-Date: | 03 Sep 2008 05:19:26 EDT |
On Mon, 01 Sep 2008 15:12:14 +0200, Michiel Helvensteijn wrote:
> An important decision we've made is that every variable in the
> language IS a strong pointer.
Well a variable cannot be null from this follows that it cannot have the
type of a strong reference (assuming that Null_Object_Error is not each
possible contract).
> That is, there is no pointer* notation.
This is a different thing. You say that a strong reference is a subtype of
the target object's type, so it has the interface of. That is OK.
Transparent pointers are very handy. Ada has pointers almost transparent.
> 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.
I am not sure if this is indeed easy.
> 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 reference has certainly a different type. But it can implement the
same interface of its target.
> 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)?
I don't see any problem, weak references can be made a copyable object. You
would copy it in and out. A copy if a weak reference is another weak
reference.
The problem is elsewhere. If you considered a system where everything is a
reference, that would not go. You need some non referential objects having
value semantics. Reference themselves need to be self values, or else you
need hyper references to references etc. The recursion of indirection must
stop somewhere.
> 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'.
By-value/reference is fully orthogonal to in/out. See Ada, which uses all
possible combinations.
> 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.
Weak references are necessary to break circular dependencies between
objects. Strong reference is basically a transitive relation "not before
me." As technical example consider a tree with operations Get_Parent,
Get_Sibling, Get_Child. A node of the tree will have four or so references
of which likely only one will be strong.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Return to the
comp.compilers page.
Search the
comp.compilers archives again.