是否记录了隐式接口变量的编译器处理？

Question

不久前我问了一个关于隐式接口变量的类似问题.

这个问题的来源是我的代码中的一个错误,因为我没有意识到编译器创建的隐式接口变量的存在.拥有它的过程完成后,该变量已完成.这反过来导致了由于变量的生命周期比我预期的更长的错误.

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

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^进行.这使例程中有两个局部变量保存对接口的引用.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 

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

但我在文档中找不到任何相关的陈述.这很重要,因为界面寿命很重要,作为程序员,您需要能够偶尔影响它.

那么,有没有人知道是否有这种行为的文件？如果没有,是否有人对它有任何了解？如何处理实例字段,我还没有检查过.当然,我可以为自己尝试一下,但我正在寻找更正式的声明,并且总是倾向于避免依赖于通过反复试验得出的实现细节.

更新1

为了回答Remy的问题,当我需要在执行另一个终结之前完成界面背后的对象时,对我来说很重要.

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

像这样写的很好.但是在真正的代码中,我有一个第二个隐式本地,它在GIL发布后被敲定并被轰炸.我通过将Acquire/Release GIL中的代码提取到一个单独的方法中来解决了这个问题,从而缩小了接口变量的范围.

Answer 1

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

procedure UseInterface(foo: IInterface);
begin
end;

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

编译器必须创建一个隐式临时变量来保存Create的结果,因为它传递给UseInterface,以确保接口的生命周期> = UseInterface调用的生命周期.该隐式临时变量将在拥有它的过程的末尾处理,在本例中是在Test()过程结束时.

您的指针赋值情况可能与将中间接口值作为函数参数传递到同一个存储桶中,因为编译器无法"看到"值的位置.

我记得多年来这个地区出现了一些漏洞.很久以前(D3？D4？),编译器根本没有引用中间值.它大部分时间都有效,但在参数别名情况下遇到了麻烦.一旦解决了这个问题,我相信有关const constms的跟进.总是希望在需要它的语句之后尽快将中间值接口的处理移动到,但我认为在Win32优化器中没有实现,因为编译器没有设置处理声明或块粒度处理.