{"id":30233,"date":"2006-08-04T07:00:00","date_gmt":"2006-08-04T14:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/2006\/08\/04\/the-implementation-of-anonymous-methods-in-c-and-its-consequences-part-3\/"},"modified":"2006-08-04T07:00:00","modified_gmt":"2006-08-04T14:00:00","slug":"the-implementation-of-anonymous-methods-in-c-and-its-consequences-part-3","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20060804-00\/?p=30233","title":{"rendered":"The implementation of anonymous methods in C# and its consequences (part 3)"},"content":{"rendered":"

\nLast time we saw how the implementation details of anonymous\nmethods can make themselves visible when you start taking a\ndelegate apart by looking at its Target<\/code>\nand Method<\/code>.\nThis time, we’ll see how an innocuous code change can result in\ndisaster due to anonymous methods.\n<\/p>\n

\nOccasionally, I see people arguing over where local variables\nshould be declared.\nThe “decentralists” believe that variables should be declared\nas close to their point of first use as possible:\n<\/p>\n

\nvoid MyFunc1()\n{\n ...\n for (int i = 0; i < 10; i++) {\n  string s = i.ToString();\n  ...\n }\n ...\n}\n<\/pre>\n
\nOn the other hand,\nthe “consolidators” believe that local variables should be\ndeclared outside of loops.\n<\/p>\n
\nvoid MyFunc2()\n{\n ...\n string s;\n for (int i = 0; i < 10; i++) {\n  s = i.ToString();\n  ...\n }\n ...\n}\n<\/pre>\n
\nThe “consolidators” argue that hoisting the variable s<\/code>\nmeans that the compiler only has to create the variable once,\nat function entry, rather than each time through the loop.\n<\/p>\n
\nAs a result, you can find yourself caught in a struggle between\nthe “decentralists” and the “consolidators” as members of\neach school touch a piece of code and “fix” the local\nvariable declarations to suit their style.\n<\/p>\n
\nAnd then there are the “peacemakers” who step in and say,\n“Look, it doesn’t matter. Can’t we all just get along?”\n<\/p>\n
\nWhile I admire the desire to have everyone get along,\nthe claim that it doesn’t matter is unfortunately not always true.\nLet’s stick some nasty code in where the dots are:\n<\/p>\n
\ndelegate void MyDelegate();\nvoid MyFunc1()\n{\n MyDelegate d = null;<\/font>\n for (int i = 0; i < 10; i++) {\n  string s = i.ToString();\n  d += delegate() {\n   System.Console.WriteLine(s);\n  };<\/font>\n }\n d();<\/font>\n}\n<\/pre>\n
\nSince the s<\/code> variable is declared inside the loop,\neach iteration of the loop gets its own copy of s<\/code>,\nwhich means that each delegate\ngets its own copy of s<\/code><\/strong>.\nThe first time through the loop, an s<\/code> is created\nwith the value \"0\"<\/code> and that s<\/code> is used\nby the first delegate.\nThe second time through the loop, a new s<\/code> is created\nwith the value \"1\"<\/code>, and that new s<\/code> is used\nby the second delegate.\nThe result of this code fragment is ten delegates, each of which\nprints a different number from 0 to 9.\n<\/p>\n
\nNow, a “consolidator” looks at this code and says,\n“How inefficient, creating a new s<\/code> each time through\nthe loop. I shall hoist it and bask in the accolades of my countrymen.”\n<\/p>\n
\ndelegate void MyDelegate();\nvoid MyFunc2()\n{\n MyDelegate d = null;\n string s;<\/font>\n for (int i = 0; i < 10; i++) {\n  s<\/font> = i.ToString();\n  d += delegate() {\n   System.Console.WriteLine(s);\n  };\n }\n d();\n}\n<\/pre>\n
\nIf you run this fragment, you get different behavior.\nA single s<\/code> variable is created for all the\nloop iterations to share.\nThe first time through the loop, the value of s<\/code> is\n\"0\"<\/code>, and then the first delegate is created.\nThe second loop iteration\nchanges the value of s<\/code> to \"1\"<\/code>\nbefore creating the second delegate.\nRepeat for the remaining eight delegates, and at the end of\nthe loop, the value of s<\/code> is \"9\"<\/code>,\nand ten delegates have been added to d<\/code>.\nWhen d<\/code> is invoked, all the delegates\nprint the value of the s<\/code>\nvariable, which they are sharing and which has the value \"9\"<\/code>.\nThe result:\n9<\/code> is printed ten times.\n<\/p>\n
\nNow, I happen to have constructed this scenario to make the\n“consolidators” look bad, but I could also have written it\nto make the “decentralists” look bad for pushing a variable\ndeclaration into a loop scope when it should have remained outside.\n(All you have to do is read the above scenario in reverse.)\n<\/p>\n
\nThe point of this little exercise is that when\na “consolidator” or a “decentralist”\ngoes through an entire program “tuning up”\nthe declarations of local variables,\nthe result can be a broken program,\neven though the person making the change was convinced\nthat their change\n“had no effect; I was just making the code prettier \/ more efficient”.\n<\/p>\n
\nWhat’s the conclusion here?\n<\/p>\n
\nWrite what you mean and mean what you write.\nIf the precise scope of a variable is important,\nmake sure to comment it as such so that somebody won’t\nmess it up in a “clean-up” pass over your program.\nIf there are two ways of writing the same thing,\nthen write the one that is more maintainable.\nAnd if you feel that one method is superior from a performance point of view,\nthen (1) make sure you’re right, and (2) make sure it matters.\n<\/p>\n
\nUpdate<\/b>:\nIn C# 5, the rules for the foreach<\/code> statement\n\nchanged in a way that affects lambda capture<\/a>:\nThe control variable of the foreach<\/code> is now scoped to the\nloop body,\nwhich means that capturing it in a lambda captures the current iteration,\nbecause each iteration gets a separate copy of th3e variable.\nThat doesn’t affect our for<\/code> loop above, but it is\nworth calling out.<\/p>\n","protected":false},"excerpt":{"rendered":"
How local variables are captured.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-30233","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
How local variables are captured.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/30233","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=30233"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/30233\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=30233"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=30233"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=30233"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}