delphi - 是否记录了编译器对隐式接口(interface)变量的处理？

我不久前问了一个类似的question关于隐式接口(interface)变量的问题。

这个问题的源头是我的代码中的一个错误，原因是我没有意识到编译器创建的隐式接口(interface)变量的存在。拥有它的过程完成时，此变量已完成。反过来，由于变量的生存期比我预期的长，导致了一个错误。

现在，我有一个简单的项目来说明编译器的一些有趣行为:

program ImplicitInterfaceLocals;

{$APPTYPE CONSOLE}

uses
  Classes;

function Create: IInterface;
begin
  Result := TInterfacedObject.Create;
end;

procedure StoreToLocal;
var
  I: IInterface;
begin
  I := Create;
end;

procedure StoreViaPointerToLocal;
var
  I: IInterface;
  P: ^IInterface;
begin
  P := @I;
  P^ := Create;
end;

begin
  StoreToLocal;
  StoreViaPointerToLocal;
end.

StoreToLocal的编译与您想象的一样。函数的结果局部变量I作为隐式var参数传递给Create。整理StoreToLocal会导致一次调用IntfClear。没有惊喜。

但是，StoreViaPointerToLocal被不同地对待。编译器创建一个隐式局部变量，并将其传递给Create。当Create返回时，执行对P^的分配。这使例程具有两个局部变量，这些局部变量保存对接口(interface)的引用。整理StoreViaPointerToLocal会导致两次调用IntfClear。
StoreViaPointerToLocal的编译代码如下:

ImplicitInterfaceLocals.dpr.24: begin
00435C50 55               push ebp
00435C51 8BEC             mov ebp,esp
00435C53 6A00             push $00
00435C55 6A00             push $00
00435C57 6A00             push $00
00435C59 33C0             xor eax,eax
00435C5B 55               push ebp
00435C5C 689E5C4300       push $00435c9e
00435C61 64FF30           push dword ptr fs:[eax]
00435C64 648920           mov fs:[eax],esp
ImplicitInterfaceLocals.dpr.25: P := @I;
00435C67 8D45FC           lea eax,[ebp-$04]
00435C6A 8945F8           mov [ebp-$08],eax
ImplicitInterfaceLocals.dpr.26: P^ := Create;
00435C6D 8D45F4           lea eax,[ebp-$0c]
00435C70 E873FFFFFF       call Create
00435C75 8B55F4           mov edx,[ebp-$0c]
00435C78 8B45F8           mov eax,[ebp-$08]
00435C7B E81032FDFF       call @IntfCopy
ImplicitInterfaceLocals.dpr.27: end;
00435C80 33C0             xor eax,eax
00435C82 5A               pop edx
00435C83 59               pop ecx
00435C84 59               pop ecx
00435C85 648910           mov fs:[eax],edx
00435C88 68A55C4300       push $00435ca5
00435C8D 8D45F4           lea eax,[ebp-$0c]
00435C90 E8E331FDFF       call @IntfClear
00435C95 8D45FC           lea eax,[ebp-$04]
00435C98 E8DB31FDFF       call @IntfClear
00435C9D C3               ret

我可以猜测为什么编译器会这样做。当可以证明分配给结果变量不会引发异常(即，如果该变量是局部变量)时，它将直接使用结果变量。否则，它将使用隐式本地，并在函数返回后复制接口(interface)，从而确保在发生异常的情况下不会泄漏引用。

但是我在文档中找不到关于此的任何声明。这很重要，因为接口(interface)生存期很重要，作为程序员，您需要能够偶尔影响它。

那么，有人知道这种行为是否有任何文件吗？如果没有人对此有更多的了解？如何处理实例字段，我还没有检查过。当然，我可以自己尝试全部操作，但是我正在寻找更正式的声明，并且始终希望避免依赖反复试验得出的实现细节。

更新1

为了回答雷米的问题，当我需要在执行另一次最终确定之前确定接口(interface)背后的对象时，这对我很重要。

begin
  AcquirePythonGIL;
  try
    PyObject := CreatePythonObject;
    try
      //do stuff with PyObject
    finally
      Finalize(PyObject);
    end;
  finally
    ReleasePythonGIL;
  end;
end;

这样写就可以了。但是在实际代码中，我有第二个隐式局部变量，该局部变量在GIL发布并遭到轰炸后最终确定。我通过将Acquire / Release GIL中的代码提取到一个单独的方法中解决了这个问题，从而缩小了接口(interface)变量的范围。

最佳答案

如果有任何有关此行为的文档，则可能在编译器生成临时变量的区域中，以在将函数结果作为参数传递时保留中间结果。考虑以下代码:

procedure UseInterface(foo: IInterface);
begin
end;

procedure Test()
begin
    UseInterface(Create());
end;

编译器必须创建一个隐式的temp变量，以保存Create传递给UseInterface的结果，以确保该接口(interface)的生存期大于等于UseInterface调用的生存期。该隐式temp变量将放置在拥有它的过程的末尾，在这种情况下，将放置在Test()过程的末尾。

指针分配的情况可能与传递中间接口(interface)值作为函数参数的情况相同，因为编译器无法“看到”该值的去向。

我记得多年来，这方面存在一些错误。很久以前(D3？D4？)，编译器根本没有引用计数中间值。它大部分时间都有效，但是在参数别名的情况下遇到了麻烦。我认为，一旦解决了这一问题，便会进行有关const params的跟进。一直希望在需要的语句之后尽快处理中间值接口(interface)，但我认为Win32优化器中从未实现过中间值接口(interface)，因为未设置编译器以便按语句或块粒度处理。

关于delphi - 是否记录了编译器对隐式接口(interface)变量的处理？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/7759081/