警告 Delphi 介面引用物件時的陷阱

用介面來接管物件引用，以此來操作該物件，這種做法很常見，也很實用。

但是，在由於delphi智慧型的介面機制，可能會讓該操作隱含陷阱

首先，讓我們簡單看一下delphi的介面機制：

一般，我們寫的介面都繼承自iinte***ce，實現介面的類也繼承自tinte***cedobject，因為它們都替我們實現了

function _addref: integer; stdcall;

function _release: integer; stdcall;

到這，問題就來了

以上兩個介面生命週期相關的函式是上述介面和類自動替我們實現的

當將乙個介面設定為nil時，它所引用的物件也會被釋放掉（的確讓人恐怖）（delphi呼叫_release）

所以，當介面引用乙個物件且這個物件的生命週期不確定時，這個自動的機制就留下了乙個不大不小的隱患。

那到這你是不是想到了，不去手動將介面設為nil？嗯，聽我接著說：

delphi的iinte***ce介面的生命週期是自管理的，因此，當這個介面不再被使用時，delphi會認為你忘記把這個位址引用置為nil了，所以你會自動給你加上，那麼歷史又重現了。

那麼怎麼樣避免這個陷阱呢？

我們不能直接將介面設為nil，為了繞開delphi的自動管理機制，我們需要先將介面轉換成指標，然後將它設為nil，這就避免了delphi認為這個介面不再被使用，自動將其設為nil。

pointer(imyinte***ce) := nil;

警告 Delphi 介面引用物件時的陷阱

用介面來接管物件引用，以此來操作該物件，這種做法很常見，也很實用。但是，在由於delphi智慧型的介面機制，可能會讓該操作隱含陷阱 首先，讓我們簡單看一下delphi的介面機制 一般，我們寫的介面都繼承自iinte ce，實現介面的類也繼承自tinte cedobject，因為它們都替我們實現了 f...

delphi使用多執行緒時，介面死鎖

以下為例子 unit unit1 inte ce uses windows messages sysutils variants classes graphics controls forms dialogs stdctrls extctrls type tform1 class tform but...

當弱引用物件成為集合元素時

當我們在系統用到某些占用記憶體較多的大物件，且該物件並不會被頻繁使 用 例如快取場景 時，考慮效能因素，或許我們可以選擇使用弱引用 weakreference 物件。弱引用物件就像是物件之中的 無間行者 行走於 活動 與 非活動 狀態之間。可能在某個時刻雖然對該物件存在引用，然而垃圾 器仍然可以對其...