delphi - 为什么 FreeAndNil 实现在 Free 之前执行 Nil ？

Question

如果您查看 FreeAndNil 过程的代码，您将看到:

procedure FreeAndNil(var Obj);
var
  Temp: TObject;
begin
  Temp := TObject(Obj);
  Pointer(Obj) := nil;
  Temp.Free;
end;

他们将Nil分配给对象引用并且仅在销毁它之后的原因是什么？为什么不反之亦然？

Answer 1

我可以想到这样做的两个原因，但似乎都没有令人信服的。

原因 1:保证在引发异常时将引用设置为 nil

实现实现了这一点。如果析构函数引发，则引用仍设置为 nil。另一种方法是使用 finally block :

try
  TObject(Obj).Free;
finally
  TObject(Obj) := nil;
end;

这样做的缺点是性能。特别是在 x86 上，try/finally 有点昂贵。在这样一个基本的例程中，谨慎的做法是避免这种开支。

为什么我觉得不惜一切代价去消除的愿望并不令人信服？好吧，一旦析构函数开始失败，你最好放弃。您无法再清楚地推断出程序的状态。您无法判断什么失败了以及您的程序处于什么状态。我认为，面对引发的析构函数，正确的行动方针是终止该进程。

原因2:确保其他线程能够检测到该对象正在被销毁

这又实现了，但没有实际用途。是的，您可以测试是否分配了引用。但然后呢？如果没有同步，另一个线程无法调用该对象的方法。你所能做的就是了解该物体是否还活着。如果是这样，那么这个状态在析构函数运行之前或之后发生变化为什么会很重要？

因此，虽然我将此作为一个可能的原因，但我无法相信内河码头的任何人真的受到这一论点的影响。