是否有必要为从 Delphi 函数返回的变量分配默认值?
渐渐地,我已经使用了更多的变体 - 它们在某些地方对于携带编译时未知的数据类型非常有用。一个有用的值是 UnAssigned(“我没有给你一个值”)。我想我很久以前就发现了这个函数:
function DoSomething : variant;
begin
If SomeBoolean then
Result := 4.5
end;
似乎相当于:
function DoSomething : variant;
begin
If SomeBoolean then
Result := 4.5
else
Result := Unassigned; // <<<<
end;
我推测这个推理必须动态创建一个变体,如果 SomeBoolean 为 FALSE,则编译器已创建它,但它是“未分配”(<; >零?)。为了进一步鼓励这种想法,如果您省略分配 Result,编译器不会报告任何警告。
刚才我发现了一个令人讨厌的错误,我的第一个示例(其中“结果”没有明确默认为“nil”)实际上从其他地方返回了“旧”值。
在返回变体时,我是否应该始终分配 Result (就像我在使用预定义类型时所做的那样)?
Gradually I've been using more variants - they can be very useful in certain places for carrying data types that are not known at compile time. One useful value is UnAssigned ('I've not got a value for you'). I think I discovered a long time ago that the function:
function DoSomething : variant;
begin
If SomeBoolean then
Result := 4.5
end;
appeared to be equivalent to:
function DoSomething : variant;
begin
If SomeBoolean then
Result := 4.5
else
Result := Unassigned; // <<<<
end;
I presumed this reasoning that a variant has to be created dynamically and if SomeBoolean was FALSE, the compiler had created it but it was 'Unassigned' (<> nil?). To further encourage this thinking, the compiler reports no warning if you omit assigning Result.
Just now I've spotted nasty bug where my first example (where 'Result' is not explicity defaulted to 'nil') actually returned an 'old' value from somewhere else.
Should I ALWAYS assign Result (as I do when using prefefined types) when returing a variant?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
是的,您始终需要初始化函数的
Result
,即使它是托管类型(例如string
和Variant)。编译器确实会生成一些代码来为您初始化
Variant
函数的未来返回值(至少我用于测试目的的 Delphi 2010 编译器会这样做),但编译器不保证您的 Result 已初始化;这只会使测试变得更加困难,因为您可能会遇到结果已初始化的情况,基于此做出决定,后来才发现您的代码有错误,因为在某些情况下结果不是已初始化。根据我的调查,我注意到:
演示:
首先,这是返回
Variant
的函数接收var 结果的证明:
隐藏参数。以下两个编译器编译为完全相同的汇编器,如下所示:变体
接下来,有趣的是看看编译器如何设置对这两个程序的调用。以下是调用具有 var X:Variant 参数的过程时会发生的情况:
如果我们将“X”设为全局变量,并调用返回 Variant 的函数,则会得到以下代码:
如果您查看此函数的序言,您会注意到用作调用
FuncReturningVar
的临时参数的局部变量被初始化为 0。如果函数不包含任何Result :=
语句,X
将为“未初始化”。如果我们再次调用该函数,则会使用不同的临时隐藏变量!下面是一些示例代码:当查看该代码时,您可能会认为返回 Variant 的函数的“结果”总是被调用方初始化为“未分配”。不正确。如果在前面的测试中我们将“X”变量设置为 LOCAL 变量(不是全局变量),则编译器将不再使用这两个单独的局部临时变量。因此,我们有两种不同的情况,编译器生成不同的代码。换句话说,不要做任何假设,始终分配
Result
。我对不同行为的猜测:如果可以在当前范围之外访问 Variant 变量,就像全局变量(或类字段)一样,编译器会生成使用线程安全的代码@VarCopy 函数。如果变量是函数的本地变量,则不存在多线程问题,因此编译器可以随意进行直接赋值(不再调用@VarCopy)。
Yes, you always need to initialize the
Result
of a function, even if it's a managed type (likestring
andVariant
). The compiler does generate some code to initialize the future return value of aVariant
function for you (at least the Delphi 2010 compiler I used for testing purposes does) but the compiler doesn't guarantee your Result is initialized; This only makes testing more difficult, because you might run into a case where your Result was initialized, base your decisions on that, only to later discover your code is buggy because under certain circumstances the Result wasn't initialized.From my investigation, I've noticed:
Demonstration:
First, here's the proof that a function returning a
Variant
receives avar Result:
hidden parameter. The following two compile to the exact same assembler, shown below:Variant
Next, it's interesting to see how the call for the two is set up by the complier. Here's what happens for a call to a procedure that has a
var X:Variant
parameter:If we make that "X" a global variable, and we call the function returning a Variant, we get this code:
If you look at the prologue of this function you'll notice the local variable that's used as a temporary parameter for the call to
FuncReturningVar
is initialized to ZERO. If the function doesn't contain anyResult :=
statements,X
would be "Uninitialized". If we call the function again, a DIFFERENT temporary and hidden variable is used! Here's a bit of sample code to see that:When looking at that code, you'd think the "Result" of a function returning Variant is allways initialized to Unassigned by the calling party. Not true. If in the previous test we make the "X" variable a LOCAL variable (not global), the compiler no longer uses the two separate local temporary variables. So we've got two separate cases where the compiler generates different code. In other words, don't make any assumptions, always assign
Result
.My guess about the different behavior: If the
Variant
variable can be accessed outside the current scope, as a global variable (or class field for that matter) would, the compiler generates code that uses the thread-safe @VarCopy function. If the variable is local to the function there are no multi-threading issues so the compiler can take the liberty to make direct assignments (no-longer calling @VarCopy).是的。
测试一下:
使用这样的函数:
在第二次调用 DoSomething 后,xx 仍将被分配。
将函数更改为:
第二次调用 DoSomething 后未分配 xx。
Yes.
Test this:
Use the function like this:
xx will still be assigned after the second call to DoSomething.
Change the function to this:
And xx is not assigned after the second call to DoSomething.