Variables Locales et Expressions Lambda

This article is available in english.

Après une petite discussion avec Eric Lippert à propos d'un post sur l'utilisation dans une expression lambda d'une variable locale déclarée dans une boucle foreach, Eric m'a fait remarquer que le morceau de code suivant :

    int a = 0;
    Action action = () => Console.WriteLine(a);
    action();


N'est pas étendu par le compilateur vers ce code :

    [CompilerGenerated]
    private sealed class <>c__DisplayClass1
    {
       public int a;

       public void <Main>b__0()
       {
          Console.WriteLine(this.a);
       }
    }

    void Main()
    {

        int a = 0;

       var display = new <>c__DisplayClass1();
       display.a = a;

       var action = new Action(display.<Main>b__0);

       action();
    }

J'ai fait une supposition sur le fait qu'une variable locale était simplement copiée dans la "display class" lorsqu'elle n'est pas utilisée après la création de la lambda, ce qui n'est pas le cas.

Si l'on prend un exemple un peu différent, avec le code suivant :

    int a = 0;
    Action action = () => Console.WriteLine(a);
    a = 42;
    action();


Ma supposition aurait fait en sorte que l'exécution de ce dernier code aurait affiché 0. Or ce n'est pas correct car les expressions lambda (et les méthodes anonymes) "capturent" la variable et non la valeur; l'exécution doit donc afficher 42.

En fait, le dernier morceau de code est étendu de la manière suivante :

    var display = new <>c__DisplayClass1();

    display.a = 0;

    var action = new Action(display.<Main>b__0);

    display.a = 42;

    action();

On peut constater dans les faits que la variable qui était auparavant locale, donc sur la pile, a été "promue" en tant que champ membre de la "DisplayClass". Cela veut dire aussi que toutes les références faites à cette variable "locale", aussi bien à l'intérieur qu'à l'extérieur de la lambda, sont remplacée vers l'instance courante de "DisplayClass".

C'est finalement très simple, mais on sent que la "magie" derrière le sucre syntaxique de C#3.0 a été assez bien pensée !

Je finirais par un grand merci à Eric Lippert qui a pris le temps de me répondre, malgré qu'il soit très probablement surchargé par le développement de C# 4.0. (avec la contravariance des types génériques, yey !)
Publié vendredi 21 novembre 2008 00:51 par jay
Classé sous ,
Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :

Commentaires


Les 10 derniers blogs postés

- Microsoft Regional Director 2.0 ! par Le blog de Patrick [MVP Office 365] le 02-23-2015, 22:10

- TechDays Paris 2015: Malware unchained par Blog Technique de Romelard Fabrice le 02-12-2015, 22:58

- TechDays Paris 2015: La transformation du SI avec le Cloud Microsoft, quel sera le rôle de la DSI demain, comment le Cloud MS accompagne cette transfo... par Blog Technique de Romelard Fabrice le 02-12-2015, 22:51

- TechDays Paris 2015: L’intranet social avec Office 365 et Yammer - quelles possibilités d’intégration ? par Blog Technique de Romelard Fabrice le 02-12-2015, 22:46

- TechDays Paris 2015: Plenière jour 3 - Vers une technologie invisible et une intelligence omniprésente ? par Blog Technique de Romelard Fabrice le 02-12-2015, 10:59

- TechDays Paris 2015: Geek is in da {new} House par Blog Technique de Romelard Fabrice le 02-12-2015, 01:13

- TechDays Paris 2015: Windows Server vNext - Virtualisation et Stockage par Blog Technique de Romelard Fabrice le 02-12-2015, 00:26

- TechDays Paris 2015: Quoi de neuf dans Windows 10 ? par Blog Technique de Romelard Fabrice le 02-11-2015, 23:37

- TechDays Paris 2015: Réussir sa migration vers Office 365 en formant les uilisateurs par Blog Technique de Romelard Fabrice le 02-11-2015, 14:32

- TechDays Paris 2015: Windows 10 et PowerShell 5.0 par Blog Technique de Romelard Fabrice le 02-11-2015, 13:10