不久前,我问过类似的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中的代码提取到一个单独的方法中来解决了这个问题,从而缩小了接口变量的范围。
答案 0 :(得分:15)
如果有任何关于此行为的文档,则在将函数结果作为参数传递时,可能会在编译器生成临时变量的区域中保存中间结果。请考虑以下代码:
procedure UseInterface(foo: IInterface);
begin
end;
procedure Test()
begin
UseInterface(Create());
end;
编译器必须创建一个隐式临时变量来保存Create的结果,因为它传递给UseInterface,以确保接口具有生命周期> = UseInterface调用的生命周期。该隐式临时变量将在拥有它的过程的末尾处理,在本例中是在Test()过程结束时。
您的指针赋值情况可能与将中间接口值作为函数参数传递到同一个存储桶中,因为编译器无法“看到”值的位置。
我记得多年来这个地区出现了一些漏洞。很久以前(D3?D4?),编译器根本没有引用中间值。它大部分时间都有效,但在参数别名情况下遇到了麻烦。一旦解决了这个问题,我相信有关const constms的后续工作。总是希望在需要它的语句之后尽快将中间值接口的处理移动到,但是我认为在Win32优化器中没有实现,因为编译器没有设置以声明或块粒度处理处理。
答案 1 :(得分:0)
您无法保证编译器不会决定创建临时不可见变量。
即使你这样做,关闭优化(甚至堆栈帧?)可能会弄乱你完美检查的代码。
即使您设法在项目选项的所有可能组合下审查您的代码 - 在Lazarus之类的代码下编译代码,甚至新的Delphi版本也会带来地狱。
最好的选择是使用"内部变量不能超过常规"规则。我们通常不知道,如果编译器会创建一些内部变量,但我们知道,当例程存在时,任何这样的变量(如果创建的话)都将被最终确定。
因此,如果你有这样的代码:
// 1. Some code which may (or may not) create invisible variables
// 2. Some code which requires release of reference-counted data
E.g:
Lib := LoadLibrary(Lib, 'xyz');
try
// Create interface
P := GetProcAddress(Lib, 'xyz');
I := P;
// Work with interface
finally
// Something that requires all interfaces to be released
FreeLibrary(Lib); // <- May be not OK
end;
然后你应该包装&#34;使用界面&#34;阻止进入子程序:
procedure Work(const Lib: HModule);
begin
// Create interface
P := GetProcAddress(Lib, 'xyz');
I := P;
// Work with interface
end; // <- Releases hidden variables (if any exist)
Lib := LoadLibrary(Lib, 'xyz');
try
Work(Lib);
finally
// Something that requires all interfaces to be released
FreeLibrary(Lib); // <- OK!
end;
这是一个简单而有效的规则。