如何正确使用ARC接口？

Question

I have a problem understanding how ARC with Interfaces exactly work. In most tutorials I have read that setting the interface to nil will call _Release , which will call Destroy , when the ARC counter reaches zero. I have read a few tutorials, but it is not yet clear to me.

type
  IXXX = interface(IInterface)
  end;

  TXXX = class(TInterfacedPersistent, IXXX)
  public
    constructor Create;
    destructor Destroy; override;
  end;


procedure TForm1.Button4Click(Sender: TObject);
var
  intf: IXXX;
begin
  intf := TXXX.Create; // IntfCopy  will be called. Message "create"
  intf := nil;         // IntfClear will be called. No message "destroy"
end;

{ TXXX }

constructor TXXX.Create;
begin
  inherited;

  showmessage('create');
end;

destructor TXXX.Destroy;
begin
  showmessage('destroy');

  inherited;
end;

When I run this program, I will get a message "create", but no message "destroy". I have looked in the assembler code and saw that calls to System._IntfCopy and System._IntfClear are made.

Looking into System._IntfClear makes clear that _Release is not called when Source is nil, which is true for intf := nil . So there is no wonder why the object is never destroyed.

But how to use ARC correctly then?

A blog recommends not touching interfaces and instead using only non-reference-counted versions. I know how to override _AddRef and _Release for bypassing/disabling ARC, but I want to use ARC, except if there is a good reason not to use it.

(Using Delphi 6)

Answer 1

The class you derive from, TInterfacedPersistent has this to say in its documentation :

TInterfacedPersistent, like all persistent objects, supports the ability to read and write its properties to and from a stream. In addition, it supplies a default implementation of the IInterface methods (_AddRef, _Release, and QueryInterface). This default implementation simply passes these calls on to the interface of the persistent object's Owner, if any.

The call to _Release is of course made when the reference count drops to zero. But nothing happens then because your object has no owner.

If you wish to use reference counting to manage the lifetime then you should dervive from TInterfacedObject instead. Or provide implementations of _AddRef and _Release that count references and destroy the object when the reference count drops to zero. Use TInterfacedObject as the template of how to implement that.

For what it is worth, the article you link to contains stunningly bad advice. Do not heed it. If you are to use interfaces, let reference counting manage lifetime, and refer to the objects only through interfaces.

Answer 2

I think you might want to use TInterfacedObject , but wrote TInterfacedPersistent instead, which does NOT manage the reference counting automatically.

Usually when I free an interfaced object, I'll always put an assertion one line before, to make sure that the object is actually an interfaced object.

procedure TForm1.Button4Click(Sender: TObject);
var
  intf: IXXX;
begin
  // create an interfaced object
  intf := TXXX.Create;

  // free an interfaced object
  if Assigned(intf) then
  begin
    assert(intf.InheritsFrom(TInterfacedObject));
    intf := nil;
  end;
end;

Note that TSingletonImplementation is yet another class that does not manage reference counting automatically.

Answer 3

Regarding the blog link you posted, it's reasonable for some condidtions, especially when a component or a control that is owned by another component.

So you said that if there is a good reason not to use it. There's one:

"If your object is a component or a control that is owned by another component, then it is part of a different memory management system that is based in TComponent. Although some classes mix the object lifetime management approaches of TComponent and interface reference counting, this is very tricky to implement correctly"

Not Using Reference Counting, the offical document said