使用方法調用從lambda到Expression很容易...public void GimmeExpression(Expression<Func<T>> expression){ ((MemberExpression)expression.Body).Member.Name; // "DoStuff"}public void SomewhereElse(){ GimmeExpression(() => thing.DoStuff());}但是我只想在少數情況下將Func轉換為表達式...public void ContainTheDanger(Func<T> dangerousCall){ try { dangerousCall(); } catch (Exception e) { // This next line does not work... Expression<Func<T>> DangerousExpression = dangerousCall; var nameOfDanger = ((MemberExpression)dangerousCall.Body).Member.Name; throw new DangerContainer( "Danger manifested while " + nameOfDanger, e); }}public void SomewhereElse(){ ContainTheDanger(() => thing.CrossTheStreams());}無效的行給了我編譯時錯誤Cannot implicitly convert type 'System.Func<T>' to 'System.Linq.Expressions.Expression<System.Func<T>>'。顯式強制轉換不能解決這種情況。有我可以忽略的設施嗎？
3 回答
料青山看我應如是
TA貢獻1772條經驗 獲得超8個贊
哦，這根本不容易。Func<T>表示通用delegate而不是表達式。如果有任何方法可以這樣做（由于優化程序和編譯器完成的其他工作，某些數據可能會被丟棄，因此可能無法恢復原始表達式），這將是在實時拆卸IL的過程。并推斷表達式（絕非易事）。將lambda表達式視為data（Expression<Func<T>>）是編譯器的一項神奇功能（基本上，編譯器在代碼中構建表達式樹，而不是將其編譯為IL）。
相關事實
這就是為什么將lambda推到極限的語言（例如Lisp）通常更易于實現為解釋器。在這些語言中，代碼和數據本質上是同一件事（即使在運行時也是如此），但是我們的芯片無法理解這種形式的代碼，因此我們必須通過在可以理解該機器的基礎上構建一個解釋器來模擬這種機器（像語言一樣由Lisp做出的選擇）或在某種程度上犧牲了功能（代碼不再完全等于數據）（C＃做出的選擇）。在C＃中，編譯器通過允許在編譯時將lambda解釋為code（Func<T>）和data（Expression<Func<T>>）的方式，給人一種將代碼視為數據的錯覺。
HUX布斯
TA貢獻1876條經驗 獲得超6個贊
private static Expression<Func<T, bool>> FuncToExpression<T>(Func<T, bool> f)
{
return x => f(x);
}
- 3 回答
- 0 關注
- 1526 瀏覽
添加回答
舉報
0/150
提交
取消