BorlandTalk.com

Ritchie · Guest

Knee-deep as I am in reference-counting, I'm a bit disappointed at
..NET's model for cleaning up objects, even though I know where they're
coming from.

..NET has three means to clean up objects, one of which is a
"convention" more than a means:

(1) If the object becomes unreachable, it goes away eventually, taking
other objects with it. Destruction code will NOT be called.

(2) The object implements IDisposable. If you call Dispose on the
object, it will run your override of Dispose.

Delphi uses this model for the destructor Destroy;, and X.Free will call
Dispose behind the scenes. This is a convention (you and your users
could just as well implement an IEatIt interface and call EatMe on it
Smile

, and recommended by Microsoft for speed reasons. Apart from that,
it's exactly like scenario # 1, above.

If you do not call .Free directly, then Destroy will *never* be called
(that may or may not be bad, depending on whether you're holding onto
limited/contentious resource sets).

(3) The object overrides Finalize; - this puts the object in a special
state where it gets collected as soon as it becomes unreachable.
Finalize will be called on it. There are technical reasons why this is
slower, including (IIRC) having to get the garbage collector on the job
right away (instead of whenever it cares to) and that Finalized objects
are in a two-pass system (once for finalizing, once for garbage
collection).

destructor Destroy; is not called in this scenario. You can call it
explicitly if you like, but you will have to be prepared to have it
called twice if you have any relevant cleanup code in the finalization
section of a unit.

---

It seems that if you want things properly 'reference-counted' (at least
for the purposes of going away), you must implement pattern # 3.
Borland's VCL-for-.NET certainly does a lot of it, especially for
database access, controls and graphics.

So for reference-counting/thread-safety, either implement pattern # 3,
or design the objects so that they have already cleaned up, or don't
care whether they're cleaned up.

As for the "weak reference pointer trick", for those who remember, where
you put the interface reference into a Pointer (instead of an IUnknown),
so that _AddRef and _Release don't get called...

TMyClass = class(TInterfacedObject,IBla)
private
FParent : Pointer;
protected
function GetParent: IBla;
procedure SetParent(const ABla: IBla);
public
// ...
property Parent: IBla read GetParent write SetParent;
end;

function TMyClass.GetParent: IBla;
begin
Result := IBla(FParent);
end;

procedure TMyClass.SetParent(const ABla: IBla);
begin
FParent := Pointer(ABla);
end;

Well, no pointers in .NET. For that matter, no _AddRef or _Release,
either :)

..NET *does* actually have something called a WeakReference. Seems simple
enough to operate:

TMyClass = class(TInterfacedObject,IBla)
private
FParent : WeakReference;
protected
function get_Parent: IBla;
procedure set_Parent(const ABla: IBla);
public
// ...
property Parent: IBla read get_Parent write set_Parent;
end;

function TMyClass.get_Parent: IBla;
var
TempObject : Object;
begin
TempObject := FParent.Target;
if TempObject=nil then
Result := nil
else
Result := IBla(TempObject);
end;

procedure TMyClass.set_Parent(const ABla: IBla);
begin
FParent := WeakReference.Create(ABla);
end;

A few points to make:

* The check in get_Parent is necessary, because "hard casts" aren't
actually hard any more - they are *all* checked, and a MyType(nil) "hard
cast" will actually fail.

* If you're wondering about the GetParent vs get_Parent oddity, just
know that if you call it GetParent (and there's a property that
references it), you'll get a hint to change it, and if you look in the
call stack from inside GetParent, you'll notice there's a get_Parent
stub that's been generated for you.

* Most annoyingly, WeakReference.Target will THROW AN EXCEPTION IF THE
OBJECT HAS BEEN COLLECTED. Instead of giving you nil. Where will this
happen? Most of the time, when the application is shutting down. Great.

* There's a WeakReference.IsAlive as well. IT THROWS THE EXCEPTION, TOO.
ACK!

I tracked down the WeakReference code from the Rotor project, and if
it's the same (it sure behaves the same), the exceptions are raised on
purpose.

So, courtesy of a little spelunking in the Rotor project, I give you a
new, very simple TWeakReference that doesn't complain :)

{$IFDEF CLR}
uses System.Runtime.InteropServices;

type
TWeakReference = class
private
FTargetHandle : GCHandle;
protected
function get_Target: TObject;
public
constructor Create(AObject: TObject);
property Target: TObject read get_Target;
end;
{$ENDIF}

{$IFDEF CLR}

{ TWeakReference }

constructor TWeakReference.Create(AObject: TObject);
begin
inherited Create;
FTargetHandle := GCHandle.Alloc(AObject,GCHandleType.Weak);
end;

function TWeakReference.get_Target: TObject;
var
IntHandle : IntPtr;
begin
IntHandle := IntPtr(FTargetHandle);
if IntPtr.Zero=IntHandle then
Result := nil
else
Result := FTargetHandle.Target;
end;
{$ENDIF}

There you go, my contribution to help your portability headaches :)

-- Ritchie Annand
Senior Software Architect
http://www.malibugroup.com
http://nimble.nimblebrain.net
http://wiki.nimblebrain.net

Nick Hodges (TeamB) · Guest

Ritchie --

This article might interest you:

http://bdn.borland.com/article/0,1410,29365,00.html

--
Nick Hodges (TeamB)
Lemanix Corporation - (http://www.lemanix.com)
Improve the quality of Delphi! Get your bugs into QC:
http://qc.borland.com

Joanna Carter (TeamB) · Guest

"Ritchie" <ritchieabatbat (AT) spamcop (DOT) netbatbat> a écrit dans le message de
news: [email]MPG.1a67a86ccb039f7d989694 (AT) forums (DOT) borland.com[/email]...

Marc Rohloff · Guest

Ritchie wrote on Thu, 8 Jan 2004 17:49:08 -0700 ...

Ritchie · Guest

In article <3ffe0e67$1 (AT) newsgroups (DOT) borland.com>, [email]nickhodges (AT) yahoo (DOT) com[/email]
says...

Ritchie · Guest

In article <MPG.1a6878cbb7c89284989d23 (AT) newsgroups (DOT) borland.com>,
[email]dont (AT) mailme (DOT) com[/email] says...

Rudy Velthuis (TeamB) · Guest

Ritchie wrote: