为什么IIf在Visual和FreeBasic中的实现是不同的？

Question

在FreeBasic中，IIf (A, B, C)等同于C/C++/Java/C#中的A ? B : C、VB.NET中的If (A, B, C)和python中的B if A else C。但是，在VB6、Office和VB.NET中，IIf (A, B, C)等同于此C++代码：

bool a = A;
auto b = B;
auto c = C;
a ? b : c;

因此，IIf在Visual和FreeBasic中的工作方式不同。例如,

Dim x As Integer, y As Integer
x = 0
y = IIf (x <> 0, 12 \ x, 0)

在FreeBasic中正常工作，但将在Visual中引发异常。这是因为在Visual中，此代码等效于以下C++代码：

int x, y;
x = 0;
bool a = (x != 0);
auto b = 12 / x;
auto c = 0;
y = a ? b : c;

在VB.NET中，使用If将与在FreeBasic中使用IIf做同样的事情。例如,

Dim x As Integer, y As Integer
x = 0
y = If (x <> 0, 12 \ x, 0)

在VB.NET中不会引发异常。

问题是:为什么VB6/VBA中的IIf (A, B, C)同时计算B和C，而不是根据表达式A的值选择一个表达式来计算

Answer 1

IIf是一个函数。它和其他功能一样工作。它不知道用于生成其参数的表达式，只知道它们的值。您在代码中编写的要传递给IIf的任何表达式都将首先进行计算，就像对任何其他方法调用一样。

2008年，VB.NET增加了一家If运营商。因为它是一个运算符，所以它的行为被输入到语言中，短路也是其中的一部分，就像它是基于C语言的三元操作符(?:)行为的一部分一样。

Answer 2

只有FreeBASIC开发人员才能肯定地回答这个问题，但以下是一些合理的推测：

• VB.NET致力于向后兼容VBA/VB6。VBA/VB6中已经存在(非短路) IIf函数.因此，使其短路将破坏向后兼容性(考虑IIf(x, SomeMethodAWithSideEffects(), SomeMethodBWithSideEffects())。因此，他们选择创建一个新的运算符If(...)。

另一方面，

• FreeBASIC从未声称/试图兼容VBA/VB6，只兼容QuickBASIC:例如，考虑它们的面向对象特性，它们具有完全不同的语法。backwards-compatibility.

从来没有QuickBASIC函数，所以他们可以使用语义稍有不同的关键字，而不必担心IIf。

现在，显而易见的后续问题是:为什么VBA/vb6的IIf操作员没有短路？再次，我只能推测，我假设他们使IIf非短路的一致性。对于一个基本的方言来说，突然出现类似于规则函数(例如IIf(a, b, c))的短路行为是令人惊讶的。但是，再说一次，这只是一个有根据的猜测。除非一个最初的开发人员意外地看到了这个问题，我不确定我们会得到一个权威的答案。

在.NET框架的第一个Beta版本中，他们将And和Or更改为逻辑短路操作符，并为最初的VBA/VB6行为引入了新的BitAnd/BitOr运算符。他们不得不在RTM版本中恢复这一更改，转而引入新的AndAlso/OrElse运算符，以避免破坏向后兼容性。