是否可以在vb.net中执行内联函数?

内联是clr(jit)的责任,在函数内联时存在一些条件:

1. 代码大小小于IL的32字节。
2. 函数不包含“复杂”结构,例如循环、开关等。
3. 函数不包含try/catch/finally。
4. 该函数未声明为虚函数。

正如您可能会发现的,32字节是 不太多 在代码方面,它适用于快速和小型if-else条件测试、属性getter/setter。我认为你不能从大量的代码中获得任何速度。

我看到的答案假设您所说的是编译或JIT时间内联——它们完全正确。然而,我听到的“inline”这个词的另一个用法是用于lambda表达式之类的东西-在c中,比如:

public IEnumerable<int> Foo()
{
    int[] numbers = new[] { 1, 5, 2, 5, 6 };

    return numbers.Select(x => x+10);
}

这个 x => x+10 (lambda表达式)在源代码术语中可以被视为“inline函数”,因为它是另一个方法中声明为“inline”的额外函数。

是的,VB9有:

Dim len As Func(Of String, Integer) = Function(x) x.Length       
Console.WriteLine(len("foo"))

我相信vb9比c有更多的限制-例如,我没有 认为 您可以创建一个 Action<T> (或具有void返回类型的任何其他委托类型)在VB9中使用lambda表达式,而在C中很容易实现。同样,我认为lambda在vb9中只能是一个表达式,而在c中,它可以是大括号中的一个完整块。

从vb10开始,也可以在vb中创建多行lambda表达式。

当然,如果问题实际上是指执行而不是源代码,那么所有这些都是无关的:)

这个问题5年后仍有一些活动(已经???)

with .net 4.5 it is now possible to specify inline method

只需使用这个属性

<MethodImplAttribute(MethodImplOptions.AggressiveInlining)>

NET团队明智地认为,这些功能在编程语言本身中没有位置,因为编译器在决定要内联什么方面更好。这是相当激进的,但事实是,现代C++实际上经常忽视 inline 有关要内联哪些函数的决策过程的说明。

这里有一个场景,当它是一个很好的设施时:

我们有一个标准的日志记录函数,传递调用方的名称通常很有用。但是,如果将日志记录设置为较低的详细程度,则日志记录函数只返回以帮助提高性能。为了避免调用方对system.reflection.methodbase.getcurrentmethod.name进行CPU代价高昂的调用,只为了日志函数不使用它们,最好创建一个内联函数,该函数事先决定是否需要查找该方法的名称:

Public Inline Function GetMyname(iLogLevel) as string
  if iLogLevel < 3 then return ""
  return System.Reflection.MethodBase.GetCurrentMethod.Name()
End Function 

然后,在打电话的人身上,我们可以放一条整齐的线,比如:

日志(2,getmyname(2)“:发生了什么事”)。

但是,如果编译器决定不内联getmyname()(正如它肯定的那样),那么日志中出现的methodname将始终是“getmyname”-一点用都没有。

称我为老式的,但是如果我们开始把所有的决定留给编译器(或者clr!)然后我们也可以寻找一个新的职业,把它留给“网络团队”。有时,软件设计师实际上最了解什么?

不能显式地将函数声明为inline,但如果JIT优化器看到好处,它可以自由地将函数声明为inline。

注意到汤姆5月11日的问题,我不得不说如果你有一份申请 真正地 性能至关重要,那么使用依赖于CLR的语言可能不是您的最佳选择。

事实上,面向对象的设计也可能不是你的最佳选择。你可能会认真地把C看作是一种选择。