為什么在“快速監(jiān)視”窗口中調(diào)試時(shí)不能使用lambda表達(dá)式？UPD：另請(qǐng)參見http://blogs.msdn.com/b/jaredpar/archive/2009/08/26/why-no-linq-in-debugger-windows.aspxhttp://blogs.msdn.com/b/jaredpar/archive/2010/06/02/why-is-linq-absent-from-debugger-windows-part-2.aspx
3 回答
胡說叔叔
TA貢獻(xiàn)1804條經(jīng)驗(yàn) 獲得超8個(gè)贊
Lambda表達(dá)式就像匿名方法一樣，實(shí)際上是非常復(fù)雜的野獸。即使我們排除Expression（.NET 3.5），仍然留下了很多復(fù)雜性，尤其是捕獲的變量，這些變量從根本上重新構(gòu)造了使用它們的代碼（您認(rèn)為變量成為編譯器生成的類中的字段） ，有一點(diǎn)煙霧和鏡子。
因此，您可以無所事事地使用它們，我一點(diǎn)也不感到驚訝-有很多支持這種魔術(shù)的編譯器工作（以及幕后的類型生成）。
動(dòng)漫人物
TA貢獻(xiàn)1815條經(jīng)驗(yàn) 獲得超10個(gè)贊
不，您不能在watch / locals /即時(shí)窗口中使用lambda表達(dá)式。正如Marc所指出的那樣，這非常復(fù)雜。不過，我想進(jìn)一步探討這個(gè)話題。
大多數(shù)人在調(diào)試器中執(zhí)行匿名函數(shù)時(shí)不會(huì)考慮的是，它不會(huì)在真空中發(fā)生。定義和運(yùn)行匿名函數(shù)的行為改變了代碼庫的基礎(chǔ)結(jié)構(gòu)。通常，尤其是從即時(shí)窗口更改代碼是一項(xiàng)非常困難的任務(wù)。
考慮以下代碼。
void Example() {
var v1 = 42;
var v2 = 56;
Func<int> func1 = () => v1;
System.Diagnostics.Debugger.Break();
var v3 = v1 + v2;
}
此特定代碼創(chuàng)建一個(gè)單個(gè)閉包以捕獲值v1。每當(dāng)匿名函數(shù)使用在其作用域之外聲明的變量時(shí)，都需要捕獲閉包。出于所有意圖和目的，此功能中不再存在v1。最后一行實(shí)際上更像以下內(nèi)容
var v3 = closure1.v1 + v2;
如果在調(diào)試器中運(yùn)行示例函數(shù)，它將在中斷行處停止?，F(xiàn)在，假設(shè)用戶是否在監(jiān)視窗口中輸入了以下內(nèi)容
(Func<int>)(() => v2);
為了正確執(zhí)行此操作，調(diào)試器（或更合適的EE）將需要為變量v2創(chuàng)建一個(gè)閉包。這很難但并非不可能。
對(duì)于EE而言，真正使這項(xiàng)工作變得艱難的是最后一行?，F(xiàn)在應(yīng)該如何執(zhí)行該行？出于所有目的和目的，匿名函數(shù)刪除了v2變量，并將其替換為closure2.v2。所以現(xiàn)在實(shí)際上需要閱讀最后一行代碼
var v3 = closure1.v1 + closure2.v2;
然而，要在代碼中實(shí)際獲得這種效果，則EE必須更改最后一行代碼，這實(shí)際上是ENC動(dòng)作。盡管可以使用此特定示例，但大部分情況都不可行。
更糟糕的是執(zhí)行l(wèi)ambda表達(dá)式不應(yīng)創(chuàng)建新的閉包。它實(shí)際上應(yīng)該將數(shù)據(jù)附加到原始閉包中。此時(shí)，您會(huì)直接遇到ENC的限制。
不幸的是，我的小例子只能解決我們遇到的問題。我一直說我會(huì)寫一篇完整的博客文章，希望這個(gè)周末有時(shí)間。
添加回答
舉報(bào)
0/150
提交
取消