gpt4 book ai didi

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

转载 作者:行者123 更新时间:2023-12-03 14:32:26 25 4
gpt4 key购买 nike

我问了类似的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 参数传递给 CreateStoreToLocal 的整理会导致对 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

为了回答 Remy 的问题,当我需要在执行另一次终结之前终结接口(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;

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

您的指针赋值情况可能与将中间接口(interface)值作为函数参数传递相同,因为编译器无法“查看”值的去向。

我记得这些年来这个领域出现了一些错误。很久以前(D3?D4?),编译器根本没有对中间值进行引用计数。它在大多数情况下都有效,但在参数别名情况下遇到了麻烦。我相信,一旦解决了这个问题,就会有关于 const params 的后续行动。总是希望将中间值接口(interface)的处理尽快移到需要它的语句之后,但我不认为在 Win32 优化器中实现了这一点,因为编译器尚未设置用于以语句或 block 粒度进行处理处置。

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

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com