使用方法調(diào)用從lambda到Expression很容易...public void GimmeExpression(Expression<Func<T>> expression){ ((MemberExpression)expression.Body).Member.Name; // "DoStuff"}public void SomewhereElse(){ GimmeExpression(() => thing.DoStuff());}但是我只想在少數(shù)情況下將Func轉(zhuǎn)換為表達(dá)式...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>>'。顯式強(qiáng)制轉(zhuǎn)換不能解決這種情況。有我可以忽略的設(shè)施嗎？
3 回答
料青山看我應(yīng)如是
TA貢獻(xiàn)1772條經(jīng)驗 獲得超8個贊
哦，這根本不容易。Func<T>表示通用delegate而不是表達(dá)式。如果有任何方法可以這樣做（由于優(yōu)化程序和編譯器完成的其他工作，某些數(shù)據(jù)可能會被丟棄，因此可能無法恢復(fù)原始表達(dá)式），這將是在實時拆卸IL的過程。并推斷表達(dá)式（絕非易事）。將lambda表達(dá)式視為data（Expression<Func<T>>）是編譯器的一項神奇功能（基本上，編譯器在代碼中構(gòu)建表達(dá)式樹，而不是將其編譯為IL）。
相關(guān)事實
這就是為什么將lambda推到極限的語言（例如Lisp）通常更易于實現(xiàn)為解釋器。在這些語言中，代碼和數(shù)據(jù)本質(zhì)上是同一件事（即使在運(yùn)行時也是如此），但是我們的芯片無法理解這種形式的代碼，因此我們必須通過在可以理解該機(jī)器的基礎(chǔ)上構(gòu)建一個解釋器來模擬這種機(jī)器（像語言一樣由Lisp做出的選擇）或在某種程度上犧牲了功能（代碼不再完全等于數(shù)據(jù)）（C＃做出的選擇）。在C＃中，編譯器通過允許在編譯時將lambda解釋為code（Func<T>）和data（Expression<Func<T>>）的方式，給人一種將代碼視為數(shù)據(jù)的錯覺。
HUX布斯
TA貢獻(xiàn)1876條經(jīng)驗 獲得超6個贊
private static Expression<Func<T, bool>> FuncToExpression<T>(Func<T, bool> f)
{
return x => f(x);
}
- 3 回答
- 0 關(guān)注
- 1520 瀏覽
添加回答
舉報
0/150
提交
取消