[fpc-pascal] Usage of TInterfacedObject. Automatic release?
Luiz Americo Pereira Camara
pascalive at bol.com.br
Mon May 28 00:28:51 CEST 2007
Marc Weustink wrote:
> Luiz Americo Pereira Camara wrote:
>> Cesar Romero wrote:
>>> Luiz Americo,
>>>> Anyway, calling manually _Release avoid the leak and i will stay
>>>> with it for now (I hope did not break anything).
>>> It can work for that case, but I think that is not a good ideia.
>>> If you are using a TInterfacedObject descendant, it will call the
>>> _Release when out of context, so in that especific case seems to
>>> never go out of context, and then you _realease call works, but in
>>> other place it can go out of context before, and the you will have
>>> others AV.
>>> - As Joao suggest, the best way is create a weak reference, where
>>> when 2 objects need to reference each other one should use Pointer
>>> to hold one reference
>>> - Avoid circular reference
>> The problem here is that i'm using a third party design. And the code
>> complexity allied with my inexperience with interfaces/COM makes the
>> chance of breaking things big.
>> Anyway i did not find, with my limitations, any circular references
>> between interfaces. Exists a circular reference but is between an
>> Interface (IVTDragManager) and a TVirtualTreeView(TCustomControl)
>> already used as a weak reference (TObject).
>> The design is more or less the following:
>> TBaseVirtualTree holds a reference to a IVTDragManager.
>> TVTDragManager (IVTDragManager) holds a reference to TBaseVirtualTree
>> stored in a TObject field
>> TVTDragManager also holds reference for IDataObject (TVTDataObject)
>> and IDropTargetHelper (returned by a win32 call)
>> TVTDataObject holds a reference to TBaseVirtualTree as a TObject
>> There are two circular references:
>> TVTDragManager <-> TBaseVirtualTree
>> TBaseVirtualTree <-> TVTDragManager > TVTDataObject > TBaseVirtualTree
> Circular references of object is not the problem, you should look at
> circular references of interfaces.
As i explained i did not found interface circular references. (Although
does not mean it does not exists ;-))
> However, I don't expect that this is the case for the virtualtree.
> THat you need a _release for fpc and not for delphi sounds like a bug
> in fpc. (only where)
This was my first idea. And now gains force again. The problem is that
the bug can not be isolated easily.
Another option is that there's a mem leak in delphi also. Does some one
know how to trace a mem leak in delphi?
More information about the fpc-pascal