Codingly

Switch sur un type en C#

Romain Verdier — Mon, 19 Oct 2009 18:41:39 +0000

Si vous avez besoin de faire un switch sur un type en C#, la première chose qu’il vous faut faire est de vous demander si vous avez besoin de faire un switch sur un type. Ensuite, demandez-vous si vous avez vraiment besoin de faire un switch sur un type, et forcez-vous à imaginer une solution tirant partie du polymorphisme (c’est presque toujours possible). Si pour une raison quelconque (imaginons-la tout de même légitime), vous ne pouvez pas faire autrement, alors voici ce qu’il faut éviter de faire :

    switch(expression.GetType().FullName)
    {
        case "System.Linq.Expressions.ConstantExpression":
            VisitConstantExpression((ConstantExpression) expression);
            break;
        case "System.Linq.Expressions.MemberExpression":
            VisitMemberExpression((MemberExpression) expression);
            break;
        case "System.Linq.Expressions.MethodCallExpression":
            VisitMethodCallExpression((MethodCallExpression) expression);
            break;
        case "System.Linq.Expressions.LambdaExpression":
            VisitLambdaExpression((LambdaExpression) expression);
            break;
        default:
            VisitExpression(expression);
            break;
    }

Aussi, si j’étais comme tout le monde (note: je ne suis pas comme tout le monde), je ferais une blague à propos de Dieu qui tue des animaux mignons à chaque fois que vous écrivez quelque chose comme :

    if(expression is ConstantExpression)
        VisitConstantExpression((ConstantExpression)expression);
    else if (expression is MemberExpression)
        VisitMemberExpression((MemberExpression)expression);
    else if (expression is MethodCallExpression)
        VisitMethodCallExpression((MethodCallExpression)expression);
    else if (expression is LambdaExpression)
        VisitLambdaExpression((LambdaExpression)expression);
    else
        VisitExpression(expression);

La bonne solution, même si elle paraitra moins concise aux plus taquins d’entre vous, est la suivante :

    var constantExpression = expression as ConstantExpression;
    if (constantExpression != null)
    {
        VisitConstantExpression(constantExpression);
        return;
    }

    var memberExpression = expression as MemberExpression;
    if (memberExpression != null)
    {
        VisitMemberExpression(memberExpression);
        return;
    }

    var methodCallExpression = expression as MethodCallExpression;
    if (methodCallExpression != null)
    {
        VisitMethodCallExpression(methodCallExpression);
        return;
    }

    var lambdaExpression = expression as LambdaExpression;
    if (lambdaExpression != null)
    {
        VisitLambdaExpression(lambdaExpression);
        return;
    }

    VisitExpression(expression);

Le safe cast évite la redondance is + cast. Rendons tout de même à césar ce qui est aux taquins : c’est un peu verbeux. Heureusement, il est assez facile de factoriser ce genre de code. J’utilise pour ma part une implémentation à base de méthodes d’extensions, qui ressemble à :

    public class Switch
    {
        public object Target { get; set; }

        public Switch(object target)
        {
            this.Target = target;
        }
    }

    public static class SwitchExtensions
    {
        public static Switch Case(this Switch @this, Action action) where T : class
        {
            if (@this == null)
                return null;

            var t = @this.Target as T;
            if (t == null)
                return @this;

            action(t);
            return null;
        }

        public static void Default(this Switch @this, Action action)
        {
            if (@this == null)
                return;

            action();
        }
    }

On retombe alors à l’utilisation sur quelque chose de concis et lisible :

    new Switch(expression)
        .Case(VisitConstantExpression)
        .Case(VisitMemberExpression)
        .Case(VisitMethodCallExpression)
        .Default(() => VisitExpression(expression));

Chaque case prend un délégué en argument. Ici, comme Action matche à chaque fois la signature des méthodes que je veux appeler (Visit*), je passe directement les method groups. Notez qu’il est tout à fait possible de faire autrement :

    new Switch(expression)
        .Case(e => Console.WriteLine("MemberExpression : " + e))
        .Case(e =>
                                    {
                                        Console.WriteLine("Rofl");
                                        VisitMethodCallExpression(e);
                                        Console.WriteLine("Lfor");
                                    });

Enfin, pour ne pas que vous vous sentiez trop lésés par cet articlet, voici en prime une photo de pingouin :

Posted in Posts Tagged: .NET, C#

Tout ce que vous n’avez pas besoin de savoir au sujet du mot clé event

Romain Verdier — Mon, 17 Aug 2009 19:23:03 +0000

Vous ne vous êtes jamais demandé à quoi servait, en C#, le mot clé event ? Moi oui. Et je vais même jusqu’à poser la question d’une certaine façon aux gens qui m’entourent, sauf peut-être dans la ligne 2 du métro :

– A quoi ça sert, le mot clé event ?
– Bah, à déclarer des events.
– Oui, mais ça marche pas sans le mot clé event ? En écrivant juste, par exemple :
public EventHandler Click;
– Heu, si, je crois.
– Donc, à quoi ça sert, le mot clé event ?
– T’es relou, dégage.

Notez qu’à l’oral, il n’y a pas la coloration syntaxique. Je suppose que c’est ce qui conduit assez régulièrement mes interlocuteurs à être désagréables. (J’aime pas les gens désagréables !)

Au risque donc que vous commenciez à m’appeler Monsieur Mauclet, j’ai bien envie de regrouper dans ce post les principales différences qui existent entre :

public EventHandler Click;

Et :

public event EventHandler Click;

Et de combattre au passage certaines confusions, parce que je me sens l’âme d’un chevalier en ce moment.

Tout d’abord — et c’est la différence fondamentale dont découle la plupart des autres — un event (syntaxiquement assimilable à un champ de type delegate modifié par le mot clé event) n’est pas un champ. Il s’agit plutôt d’une sorte de propriété un peu spéciale revêtant une sémantique particulière : un event est explicitement, heh, un évènement.

Concrètement, écrire :

public event EventHandler Click;

Est équivalent à :

private EventHandler click;
public event EventHandler Click
{
	add { this.click += value; }
	remove { this.click -= value; }
}

Le code ci-dessus est valide en C#. Par défaut, un évènement possède des “accesseurs”, add et remove, qui permettent respectivement d’ajouter et de supprimer des handlers à un champ privé, de type delegate. Notez qu’il s’agit ici de l’implémentation générée par le compilateur lorsque vous utilisez la déclaration classique d’un event, mais il est tout à fait possible de changer cette implémentation : vous êtes en effet libre de mettre ce que vous voulez dans le add et le remove. A vrai dire, un event n’est que ce couple add/remove.

Exemple !utile :

private EventHandler click;
private int handlerCount;
public event EventHandler Click
{
	add
	{
		this.click += value;
		this.handlerCount++;
	}
	remove
	{
		this.click -= value;
		this.handlerCount--;
	}
}

Il est intéressant de faire l’analogie entre la façon usuelle de déclarer un event et l’écriture d’une propriété automatique. Dans les deux cas, le compilateur fait le grunt work, et se charge donc de générer le backing field encapsulé par l’event ou la propriété, ainsi que la logique associée (affectation/lecture de la valeur ou ajout/suppression du handler), parce que la plupart du temps, c’est effectivement ce que l’on désire. Dans les deux cas, au risque de me répéter, il est possible de reprendre la main et de faire ce que l’on veut en proposant une implémentation différente des accesseurs (get/set pour les propriétés, add/remove pour les events).

En résumé, un event n’est pas un champ, un delegate, ou un truc de facebook ; non, un event en C# est un moyen d’exposer de façon normalisée, deux méthodes permettant d’enregistrer/désenregistrer des handlers. C’est tout.

Je crois qu’il faut bien faire la différence entre ce qu’est un event par définition, et ce que le compilateur génère par défaut pour nous aider. On peut très bien déclarer un event sans avoir de backing field, comme c’est aussi le cas pour les propriétés. Un-event-c’est-deux-méthodes.

Bon.

Après ce petit rappel, on devrait se sentir un peu plus à l’aise pour commencer l’énumération inutile de tout ce qui distingue plus ou moins évidemment un event d’un Champ Public De Type Delegate (CPDTD).

Protection

Lorsque vous exposez un CPDTD, n’importe qui est capable de le référencer et de le manipuler en tant que tel. Ce n’est pas le cas lorsque vous déclarez un event, puisque seules deux méthodes d’ajout/suppression de handler sont exposées. Du coup, l’invocation d’un event est restreinte : seul le type qui porte l’évènement peut déclencher ce dernier, les autres types devant se contenter de fournir leurs handlers en utilisant modestement les accesseurs.

Attention, même les types dérivés perdent le privilège d’invocation; on devra donc la plupart prévoir une méthode protected pour contourner la limitation.

Interfaces

Puisqu’un event-c’est-deux-méthodes, il peut apparaitre dans une interface, alors qu’un CPDTD, non. C’est très important, et très logique. Il est compréhensible en effet qu’on puisse s’engager à “exposer” deux méthodes dans un contrat, mais pas un champ.

Polymorphisme

Puisqu’un event-c’est-deux-méthodes, toujours, on peut parler de polymorphisme, et appliquer aux events les modifiers qu’il est habituellement possible d’appliquer aux méthodes. Implicitement, ils concerneront les deux accesseurs add et remove. Cela signifie qu’un event peut être abstract, virtual ou même sealed. De même, on peut overrider ou redéfinir un event à l’aide des mots clés override et new.

Pas le droit lol

Le fait qu’un event ait toujours des accesseurs (add/remove) implique que les fonctions correspondantes existent déjà. Ainsi, il est impossible d’écrire :

public event EventHandler Click;

public void add_Click(EventHandler handler) {} // Erreur : signature existante
public void remove_Click(EventHandler handler) {} // Erreur : signature existante

Opérateurs

Lorsqu’utilisés avec les delegates, les opérateurs += et -= ne sont pas interprétés comme la combinaison condensée d’une addition/soustraction + une affectation. le type Delegate ne surcharge d’ailleurs ni l’opérateur +, ni l’opérateur -. En fait, le compilateur remplace += et -= par les appels respectifs aux méthodes statiques Delegate.Combine et Delegate.Remove, qui retournent de nouvelles instances de délégués. (Un délégué est immutable)

Par contre, lorqu’on utilise += et -= pour ajouter/supprimer un handler à un event, le compilateur travaille différemment et se charge d’appeller directement les accesseurs de l’évènement.

Si Click est un CPDTD :

button.Click += OnClick;
// Compilé en :
// button.Clik = (EventHandler) Delegate.Combine(button.Clik, new EventHandler(OnClick));

Si Click est un event :

button.Click += OnClick;
// Compilé en :
// button.add_Click(new EventHandler(OnClick));

Warnings

Puisqu’il est uniquement possible de déclencher un évènement à l’intérieur de la classe qui contient sa déclaration, le compilateur est capable de lever un warning lorsqu’il ne détecte aucune invocation de l’évènement.

Evaluation

En C#, une affectation est une expression évaluable. On peut écrire, par exemple :

int i = 12;
int j = i = 6; // (i = 6) est évalué, de type int, donc le code est valide et j vaudra 6.

De même, lorsque Click est un CPDTD, il est possible décrire :

EventHandler handler = button.Click += OnClick;

Car l’expression button.Click += OnClick est de type EventHandler.

Mais dans le cas où Click est un event, button.Click += OnClick est de type void, du coup le code précédent ne compile pas.

Reflection

Si on veut accéder à un CPDTD par la réflexion, on utilise la méthode GetField ou GetFields. Mais comme les events sont des animaux bien différents, il existe les méthodes GetEvent et GetEvents, qui retournent des instances d’EventInfo. J’ai insisté là dessus précedemment : la notion d’event n’est liée à celle de backing field que parce qu’il s’agit d’une association constatée dans 99% des implémentations, mais c’est tout. Il est impossible d’optenir les métadonnées relatives au backing field d’un event à partir de son EventInfo, tout comme il est impossible d’obtenir les métadonnées relatives au backing field d’une propriété à partir de son PropertyInfo.

Enfin si, c’est possible, mais chut.

Interop

Si vous kiffez COM, sachez que les CPDTD ne vous seront d’aucune utilité au cas où vous chercheriez à interopérer avec des évènements COM. Il faudra forcément utiliser des events. Et ne me dites pas que c’est évident~~, où je vous tue.~~

Doudounotte

Microsoft propose une guideline relative aux events :

…the delegate type used for an event should take two parameters, an “object source” parameter indicating the source of the event, and an “e” parameter that encapsulates any additional information about the event. The type of the “e” parameter should derive from the EventArgs class. For events that do not use any additional information, the .NET Framework has already defined an appropriate delegate type: EventHandler.

Ce n’est qu’un encouragement, hein, vous êtes libre d’avoir des events de type Action>, Guid>, bool> si vous le souhaitez. Néanmoins, l’idée est louable, puisque si le conseil est suivi, la contravariance permettrait à la méthode suivante de devenir un handler universel :

public void OnEvent(object sender, EventArgs e)
{
}

Je suppose que c’est l’ambition très secrète de toutes les méthodes du monde. En tout cas, si j’étais une méthode, l’idée me séduirait.

Synchronisation

Pour les events, lorsqu’on laisse le compilateur générer le backing field et les accesseurs, ces derniers seront automatiquement synchronisés. Le compilateur associera en effet l’attribut MethodImpl avec l’option MethodImplOptions.Synchronized aux méthodes add et remove, ce qui est fonctionnellement équivalent à prendre un lock sur l’instance ou le type, selon si l’event est ou non statique.

Par contre, si vous préférez fournir votre propre implémentation pour les accesseurs, ce sera à vous de prévoir la synchronisation en utilisant un lock manuellement, si nécessaire.

Merci Patrice !

Menteur

Si un event n’est que deux méthodes, comment se fait-il alors, gros malin, que l’on puisse écrire et compiler :

public event EventHandler Click;

public void ICanHazInvokashun()
{
    Click(this, EventArgs.Empty);
}

En effet, un évènement est bien invocable. Ca voudrait dire que le compilateur est capable de tricher, et d’appeler sournoisement la méthode Invoke sur le champ privé caché ? Et bien oui. Le pseudo IL du corps de ICanHazInvokashun ressemble à :

ldarg.0
ldfld class System.EventHandler Button::Click
ldarg.0
ldsfld class System.EventArgs System.EventArgs::Empty
callvirt instance void System.EventHandler::Invoke(object, class System.EventArgs)
ret

A la ligne 2 on constate que c’est bien un champ (ldfld = load field) qui est poussé sur le pile et sur lequel on appelle la méthode Invoke (ligne 5). A quoi d’autre pouvions-nous nous attendre ?

Si on décide de fournir une implémentation différente pour add et remove, le compilateur ne devrait plus être en mesure de permettre l’invocation directe de l’évènement avec la même syntaxe :

public event EventHandler Click
{
    add { /* rien */ } remove { /* pas mieux */ }
}

public void ICanHazInvokashun()
{
    Click(this, EventArgs.Empty); // Haha j't'ai foolé, sale compiler.
}

Effectivement, il n’est plus possible de compiler la ligne 8, et on obtient le message d’erreur généralement réservé aux utilisateurs du type qui expose l’évènement :

The event ‘Button.Click’ can only appear on the left hand side of += or -=

Voilà. Certes, c’était un post un peu facile, et tout ça n’est pas très excitant. Mais après tout, qu’est-ce qui peut bien être excitant en C# ? On parle d’un langage de programmation ! Alors à moins d’être un fanboy, etc.

Posted in Articles Tagged: .NET, C#

Je ne suis pas Joel Spolsky

Romain Verdier — Wed, 05 Aug 2009 13:53:01 +0000

Je ne sais pas si vous avez remarqué, mais Joel a carrément sauté le requin. Avant, son blog était maintenu, la plupart du temps drôle, et généralement intéressant. Maintenant, il ne poste plus rien, ou très rarement. Pire : souvent il ne poste que pour signaler qu’il vient d’écrire un article sur Inc. Du coup ses billets ressemblent à ça (sur 8 lignes) :

From my latest Inc. column : “Blah blah blah”

Bon, moi, je ne suis pas Joel Spolsky car je n’ai pas tenu 10 ans avant de sauter le requin.

Extrait de mon dernier compte-rendu sur altnetfr.org :

Par contre, Yann ne sait pas coder :

for(int i=0; i< 100000000; i++) { if(!list.Contains(Guid.NewGuid().ToString())) list.Add(Guid.NewGuid().ToString()); }

Il faut probablement avoir une maladie mentale pour écrire ça ! C’est en tout cas ce que j’ai pensé sur le coup, en pouffant sur ma chaise (j’étais au fond de la salle). Ensuite, je ne sais plus si je l’ai compris de moi même ou si Yann a dû le préciser d’un air atterré, mais il avait fait exprès d’écrire ça. Parce que d’autres ne font pas exprès, et que ça pose des problèmes.

C’était au sujet de la dernière rencontre ALT.NET parisienne, où Yann Schwartz nous parlait de Windbg et d’autres trucs. C’était très bien.

Posted in Posts Tagged: .NET, ALT.NET

ALT.NET en France : Présentation AOP, c’est fait.

Romain Verdier — Thu, 18 Jun 2009 08:09:28 +0000

Je me demande si 91 slides valent 1000 mots. Vous pourrez essayer de vous faire une idée puisqu’elles sont disponibles ci-dessous. Je vous conseille de carrément télécharger la présentation si vous êtes intéressés par les animations, puisque certaines (lire : toutes) sont très logiquement tuées par SlideShare.

Bon, pour ma part j’ai trouvé que ça s’était plutôt bien passé considérant que je ne suis pas un speaker – au mieux un sale programmeur – même si j’imaginais une présentation un peu plus courte. J’ai parlé pendant 45 min, je crois, puis j’ai ouvert VS pour la “démo interactive” qui s’est un peu éternisée.

Je tiens encore à remercier FastConnect pour la salle, l’organisation, le buffet, etc.

En ce qui concerne le code des exemples, j’essaierai d’éditer ce post ultérieurement.

Edit Quelques liens en rapport :

Edit Le compte rendu de la soirée est maintenant dispo sur le site ALT.NET Fr. Merci Jb.

N’hésitez pas à me faire part de vos critiques positives, puisque les autres, constructives ou pas, elles vexent. OK ?

Posted in Posts Tagged: .NET, ALT.NET, AOP

ALT.NET en France : Présentation AOP à Paris le 17 juin

Romain Verdier — Tue, 02 Jun 2009 21:18:28 +0000

Avant toute chose : Non, je ne chercherai pas à justifier le rythme misérable de mes publications sur ce blog. Et non, je ne m’excuserai pas de tricher lamentablement en postant aujourd’hui quelque chose d’aussi, heu, bref.

Je voulais vous informer, ou plus probablement vous rappeler, que j’allais commettre une présentation sur l’AOP, le 17 juin, à l’occasion de la 14ème rencontre ALT.NET Parisienne. Vous trouverez les détails pratiques sur notre joli site. Merci à FastConnect qui sponsorise l’évènement.

Il va sans dire que je serais plus à l’aise s’il n’y avait que 3 personnes qui jugeaient bon de se déplacer. Pourtant, je vais m’asseoir sur cette considération et vous inviter à venir nombreux. Plusieurs fois au cours des rencontres précédentes nous avons abordé la question de la programmation orientée aspect lors des discussions libres, et il semblerait donc que le sujet rende curieux, à défaut de préoccuper. Peut-être mérite-t-il que nous lui fassions plus de place le temps d’une soirée. Je ne sais pas encore exactement quel sera l’agenda, mais l’idée est de présenter l’AOP en tant que concept, de le confronter gentiment aux paradigmes traditionnels, avant de passer plus concrètement à l’étude des différentes techniques et outils qui existent en .NET.

D’aucuns pourraient penser que le sujet n’est pas spécialement ALT.NET.

Ce à quoi je répondrais :

Certes, certes…

Enfin. Si on compte uniquement sur Microsoft pour profiter de l’AOP on risque assez rapidement de se sentir à l’étroit. Il est possible de faire de l’AOP sans sortir de la BCL, oui, et il est possible de faire de l’AOP un peu plus facilement en débordant sur EntLib. Cependant, les solutions les plus matures et les plus riches pour faire de l’AOP en .NET ne sont pas forcément estampillées Microsoft, ce qui risque de conduire l’utilisateur averti vers des frameworks plus spécialisés, open-source ou pas. Je veux parler de Castle.DynamicProxy, PostSharp, Linfu, Mono.Cecil, Spring.NET, etc.

Moi, je trouve que ça sent ALT.NET.

Bref, j’espère que cette rencontre verra naitre un débat et que nous pourrons collecter quelques retours d’expériences, comparer nos approches, bailler, etc. Encore une fois, toutes les infos sont disponibles sur le site altnetfr, à cette adresse.

Pensez à vous inscrire, et n’hésitez pas à faire passer l’info.

Posted in Posts Tagged: .NET, ALT.NET, Annonce, AOP

Petit rappel sur le Disposing Pattern en C#

Romain Verdier — Wed, 01 Apr 2009 09:02:14 +0000

Ca fait longtemps que je veux faire ce post, au sujet d’une question trop souvent négligée : le disposing pattern. On peut voir ça comme un petit rappel, ou un post à classer dans la catégorie “back to basics”. En deux mots, il s’agit de gérer correctement la libération des ressources non-managées, dans un programme managé.

EDIT : Ce post est un poisson d’avril, évidemment. Il vaudrait mieux ne pas utiliser l’implémentation du disposing pattern proposée…

Quelques rappels

On parle de code managé en .NET car on fait implicitement référence au garbage collector qui gère automatiquement la mémoire. Il n’est pas question de faire un cours sur le GC, mais retenez juste qu’il est très intelligent, et qu’il est indépendant. Tellement indépendant qu’on ne peut pas prévoir quand est-ce qu’il va réellement effectuer son recyclage. Par exemple, lorsque vous écrivez :

public int Add(int a, int b)
{
    Calculator calculator = new Calculator();
    return calculator.Add(a, b);
};

Vous créez une nouvelle instance de Calculator qui sera référencée par la variable locale calculator. A la sortie de la méthode, la variable locale n’existe plus, et l’instance de Calculator n’est donc plus référencée. L’espace mémoire qu’elle occupe peut être récupéré, et le GC le sait. (Notez l’assonance.) Il y a un instant j’insistais sur l’indépendance du garbage collector : s’il sait qu’il peut libérer une instance, vous ne savez pas quand il le fera.

On considère que la collecte des miettes est indéterministe. Vous n’avez aucun moyen de savoir précisément quand le calculator que vous avez instancié précédemment sera collecté. Ca ne sera pas forcément à la sortie de la méthode, comme on pourrait naïvement s’y attendre ; ça peut être 47 ms ou 47 secondes après (pour caricaturer) et vous devriez même être heureux de ne pas avoir à vous en soucier.

Mais.

Tout n’est pas managé. Parfois, vous utilisez à partir d’objets managés des ressources non managées. Même si ça peut paraitre évident, il est bon de revenir là dessus. On parle de “ressource non managée” dans ce contexte pour décrire une ressource :

Dont l’allocation est déclenchée à partir de votre code managé.
Qui doit être libérée.
Mais dont le garbage collector n’est pas responsable.

Les handles de fichiers, les connexions de bases de données, les sockets réseau ou les références COM sont des exemples de ressources non managées.

Comment implémenter le disposing pattern

On se base sur l’interface IDisposable, et sur les destructeurs de C#. IDisposable expose une méthode Dispose, qui va détruire l’objet, et faire en sorte que sa mémoire soit désallouée du heap (et non pas de la pile comme je le vois souvent dans des blogs), surtout si on fait bien appel au mot clé using qui ne sert pas qu’à importer des namespaces.

Mais assez de théorie, passons au code. Imaginons la classe C# suivante, et regardons comment elle fait pour libérer le IntPtr qu’elle a en variable publique et qui constitue sa variable non managée dangereuse (attention aux memory leaks lol) :

EDIT : Ce post est un poisson d’avril, évidemment. Il vaudrait mieux ne pas utiliser l’implémentation du disposing pattern proposée…

public class MaClasseManagée : IDisposable // on implémente IDisposable
{
    private IntPtr m_Ressource_non_managée; // Attention !
	bool disposed = false; // pour savoir si la classe est libérée  

    public MaClasseManagée(IntPtr ptrnonmanagé)
    {
		if(ptrnonmanagé != null)
		{
			m_Ressource_non_managée = ptrnonmanagé; // allocation mémoire non managée
		}
		else // sinon
		{
			if (ptr.Equals(IntPtr.Zero) == true)
            {
                // on désalloue directement la mémoire du pointeur
				m_Ressource_non_managée = IntPtr.Zero
            }
			GC.CancelFullGCNotification(); // pas obligé, mais il vaut mieux
		}
    }

	public void FaireQuelqueChose()
	{
		// ici on utilise la ressource non managée qui a été allouée
		// ...
		// ...
	}

	// destruteur de la class
	~MaClasseManagée()
	{
		// partie un peu tricky : on interdit au CLR de supprimer l'instance
		// courante car ça a déjà été fait dans le Dispose d'IDisposable
		GC.SuppressFinalize(this);

		// on s'assure quand même qu'on garde pas de référence vers le pointeur
		m_Ressource_non_managée = IntPtr.Zero;
	}

	// methode dispose la plus importante
    public void Dispose()
    {
        if(!disposed)
        {
			// on appelle le garbage collector, et on force la libération de
			// tous les objets pour être certains de plus référencer des variables
			// non managées depuis C#
			GC.Collect();

			disposed = true; // déja disposé
        }
    }
}

Notez donc qu’il faut bien faire la différence entre le constructeur, le destructeur, et le dispose. Trop souvent les gens oublient l’un des trois, et compromettent du coup la sécurité de leur code.

A l’utilisation c’est simple :

// mot clé using
using(MaClasseManagée obj = new MaClasseManagée())
{
	// manipuler obj
	obj.FaireQuelqueChose();
}
// à la sortie du bloc using, le garbage collector est appellé et libère le tas
// des instances de MaClasseManagée persistantes, donc, forcément avec notre
// pattern, des ressources non managées IntPtr aussi

Et voilà :)

Je compte faire un article bientôt sur une nouvelle façon d’appréhender cette problématique avec l’AOP, notamment dans les architectures distribuées où il y a trop de code à écrire pour qu’on puisse se permettre de perdre du temps avec ces considérations bas niveau dans un contexte économique délicat (c’est la crise !) qui nous force à économiser le temps et l’argent sans pour autant arrêter de produire des logiciels de qualité qui donneront satisfaction au client et permettront aux développeurs de ne pas s’arracher les cheveux sur des solutions de 50 projets où les autres ont fait n’importe quoi et qu’il faut quand même livrer coute que coute tant pis pour les nuits blanches (ça serait quand même un comble de ne plus être en mesure de maitriser son métier, ou de devoir arrêter la qualité sous prétexte que c’est les chefs de projets qui décident des planning sans rien comprendre de la technique alors que c’est la base).

Posted in Posts Tagged: .NET, C#, WTF

Nouveau site pour ALT.NET France

Romain Verdier — Mon, 02 Mar 2009 10:21:03 +0000

Enfin ! Nous avions un groupe de discussion depuis le début, et nous squattions à droite et à gauche lorsqu’il était nécessaire de communiquer et de s’organiser, mais depuis quelques jours nous avons notre vrai portail. Un grand merci à Julien pour son travail, et à ceux qui ont commencé à contribuer à l’élaboration du contenu :

www.altnetfr.org

ALT.Net est un groupe de développeurs .NET passionnés, cherchant à améliorer la façon dont les logiciels sont développés. Nous reconnaissons qu’il n’y a pas de solution unique à un problème mais qu’il y a une multitude d’alternatives pouvant être appliquées dans différentes situations.

Le but était d’offrir une façade à la communauté ALT.NET de France. Jusqu’alors il fallait être spécialement motivé pour parvenir à comprendre ce qu’était ALT.NET, et encore un peu plus pour oser venir aux rencontres. Le nouveau site devrait donc répondre à ces deux besoins, en décrivant le mouvement et ses principes d’une part, et en proposant l’agenda des différents évènements que nous organisons d’autre part.

La dernière réunion a permis à Nicolas Roux et Frédéric Fadel de nous présenter Aspectize, et un compte rendu a déjà été posté par Gauthier. En Mars, il sera question de TDD, et c’est Djamel Zouaoui et Frédéric Schäfer qui animeront la présentation dans les locaux d’Octo. Nous comptons continuer de la sorte en annonçant les réunions futures et en proposant des comptes-rendus régulièrement. N’hésitez d’ailleurs pas à soumettre vos contributions ; un effort collaboratif ne peut qu’être profitable.

Pour ceux qui ne sont pas spécialement enclins à rédiger des comptes-rendus ou à proposer des articles, notez qu’il existe un wiki, qui offre déjà à tous la possibilité de participer sans contrainte particulière à l’enrichissement des ressources ALT.NET en français.

Bref, vous êtes chaudement invités à :

Ajouter altnetfr.org dans vos readers
Proposer vos comptes-rendus, vos articles, etc.
Venir à la prochaine réunion (et aux autres)
Faire passer le mot au sujet d’ALT.NET France !

Si les types étaient des animaux, TypedReference serait un ornithorynque

Romain Verdier — Thu, 15 Jan 2009 00:08:29 +0000

Devinette : C’est un type valeur, mais on ne peut pas le caster en object. Il est impossible d’en déclarer des tableaux. On ne peut l’utiliser que pour typer les paramètres de méthodes et les variables locales. Il existe 4 mots clés non documentés en C# qui lui sont directement reliés, et autant d’opcodes en CIL. Il permet notamment le support des varargs, et exactement 8 personnes dans le monde se sont souciées plus de 5 min de son existence.

Je veux parler, bien évidemment, de TypedReference. Je vous propose de découvrir ce type à partir d’un exemple rigolo.

Méthodes varargs et interopérabilité

En C#, lorsqu’on veut définir une méthode à nombre de paramètres variables, on utilise la syntaxe suivante :

public static double Average(params int[] values)
{
    double sum = 0;
    foreach (var i in values)
        sum += i;
    return sum / values.Length;
}

Notez le mot clé params qui permet l’appel de la méthode en passant un tableau en paramètre, ou en listant plus librement les arguments :

var parameters = new int[]{45, 68, 97, 45};
ManagedClass.Average (parameters)
// ou bien
ManagedClass.Average (45, 68, 97, 45)

En C++ / CLI, la syntaxe est un peu différente mais le principe est le même :

double CodinglyInterop::CppCliLibrary::average(... array ^values)
{
	double sum = 0;
	for each (int i  in values)
		sum += i;
	return sum/values->Length;
}

C’est pareil, en plus moche. On utilise “...” au lieu de “params“, et l’appelant peut passer un tableau ou une liste d’arguments :

var parameters = new int[]{45, 68, 97, 45};
CppCliLibrary.average(parameters)
// ou bien
CppCliLibrary.average(45, 68, 97, 45)

Notez que l’interopérabilité entre C# et C++/CLI est native : les deux langages sont managés.

Et en C++ pas CLI, qu’est-ce que donnent les fonctions à nombre variable d’arguments ?

Bah c’est encore plus moche, et plus contraignant. Rappelez-vous :

extern "C" __declspec(dllexport) double average(int n, ...)
{
	double sum = 0;
	va_list args;
	va_start(args, n);
	for(int i=0 ;i < n; i++)
		sum += va_arg(args, int);
	va_end(args);
	return sum/n;
}

La principale différence est finalement assez subtile on n’utilise pas explicitement un tableau, mais on fournit un pointeur vers le début de la liste d’arguments. C’est à la méthode de se débrouiller (avec des macros) pour itérer, caster et s’arrêter lorsqu’il le faut. Généralement, un autre paramètre nommé de la méthode contient les infos nécessaires à cette opération. Dans l’exemple précédent, “n” est utilisé pour passer directement le nombre d’arguments de la liste. Dans printf, c’est la format string qui permet à la fonction de savoir combien d’arguments elle doit lire.

La question rigolote, puisque nous sommes dans le contexte d’un exemple rigolo, est la suivante :

Mais comment appeler les fonctions natives de ce genre depuis C# ? En utilisant pinvoke, probablement, mais plus précisément ?

Réponse : En pleurant. On est obligé de déclarer explicitement les imports pour chacune des utilisations que l’on va faire de la fonction dans notre code managé. En gros :

[DllImport ("NativeLibrary.dll")]
public static extern double average (int n, int i1);

[DllImport ("NativeLibrary.dll")]
public static extern double average (int n, int i1, int i2);

[DllImport ("NativeLibrary.dll")]
public static extern double average (int n, int i1, int i2, int i3);

[DllImport ("NativeLibrary.dll")]
public static extern double average (int n, int i1, int i2, int i3, int i4);

// Etc.

What a PITA, comme qui dirait… Mais c’est ici que l’ornithorynque nous sauve la vie. Car on peut écrire :

[DllImport ("NativeLibrary.dll", CallingConvention = CallingConvention.Cdecl)]
public static extern double average (int n, __arglist );

Et appeler la fonction ainsi :

NativeWrapper.average (4, __arglist (45, 68, 97, 45))

Hourra, donc. Mais quel est ce mot clé bizarre, __arglist, qui n’est même pas reconnu par Resharper ? Et bien il s’agit d’un des mots clés non documentés du langage, qui permettent principalement de jouer avec les TypedReference. Pour mieux comprendre ce qui se passe, essayons de réécrire en C# la méthode Average, sans utiliser le mot clé params, et en se reposant donc uniquement sur les “références typées”. On s’attaquera ensuite à la définition.

public class ManagedEvil
{
    public static double Average(__arglist)
    {
        double sum = 0;
        int count = 0;
        var iterator = new ArgIterator(__arglist);
        do
        {
            TypedReference typedReference = iterator.GetNextArg();
            sum += __refvalue( typedReference,int);
            count++;
        } while (iterator.GetRemainingCount() > 0);
        return sum / count;
    }
}

On note :

L’apparition du type ArgIterator, dont on crée une instance à partir de la liste d’arguments.
L’élément courant retourné par l’itérateur est une référence typée : TypedReference.
Un nouveau mot clé, __refvalue, permet d’extraire la valeur pointée par la référence.

Et tout ça compile, tout ça fonctionne, même si l’intérêt est limité.

`TypedReference`, `makeref`, `refvalue`, `__reftype`

Arrêtons les expériences pour décortiquer un peu plus sérieusement ce TypedReference. La MSDN définit ~~très clairement~~ la TypedReference :

Describes objects that contain both a managed pointer to a location and a runtime representation of the type that may be stored at that location.

Retenons qu’il s’agit d’une structure contenant :

Un pointeur managé vers un espace mémoire
Le type de ce qui est pointé en mémoire

Le meilleur endroit pour trouver des infos au sujet de TypedReference est finalement la spécification ECMA 335 du CIL. Je vous laisse fouiller, mais sachez que les bases sont notamment posées dans le paragraphe suivant (cf. 8.6.1.3):

La signature d’une référence typée est en fait représentée en tant que type valeur de base, comme les entiers ou nombres à virgule flottante. Dans la bibliothèque de classes du framework, le type est représenté par System.TypedReference, tandis que dans le langage intermédiaire il est désigné par le mot clé typedref. Ce type doit uniquement être utilisé pour les paramètres et les variables locales. Il ne peut ni être boxé ni être utilisé pour typer un champ, un élément de tableau, ou une valeur de retour de fonction.

Pour que je ne puisse jamais justifier l’intérêt de cet article, les gens chez Microsoft ont bien fait attention à exposer ce type le moins possible. Il est pourtant assez utilisé en interne, notamment dans System.Array, System.Threading.Interlocked, les services d’intérop (InteropServices) ainsi que dans certains overloads cachés utilisant les varargs (String.Concat, Console.WriteLine). A vrai dire, il semblerait que la raison officielle de son existence soit justement le support par le CLR des listes d’arguments, comme nous l’avons vu plus tôt. Il existe cependant un autre endroit (parmi d’autres) où son utilisation peut s’avérer intéressante : la réflexion via les FieldInfo. Mais avant d’y venir, regardons plutôt comment utiliser, très mécaniquement, TypedReference. On peut soit utiliser les mots clés interdits, soit – lorsque c’est possible – utiliser les quelques méthodes statiques de la classe TypedReference elle-même.

Création d’une référence typée : __makeref

Les références typées peuvent être obtenues pour des variables de n’importe quel type (référence ou valeur) à l’aide du mot clé __makeref.

int i = 42;
TypedReference typedReference = __makeref (i);

Ce mot clé dont l’usage n’est pas documenté correspond à l’instruction mkrefany en CIL. Le code intermédiaire correspondant à l’exemple précédant est le suivant :

int i = 42;

L_0000: ldc.i4.s 0x2a	/* push sur la pile d'un int32 = 42						*/
L_0002: stloc.0			/* sauvegarde dans la variable locale i					*/

TypedReference typedReference = __makeref(i);

L_0003: ldloca.s i		/* push sur la pile de l'adresse de i					*/
L_0005: mkrefany int32	/* push sur la pile de la référence typée				*/
L_000a: stloc.1			/* sauvegarde dans la variable locale typedReference	*/

La méthode statique TypedReference.MakeTypedReference permet aussi de créer des références typées, mais pas directement à partir d’une variable. Nous verrons un exemple d’utilisation dans la dernière partie de l’article.

Récupérer et/ou modifier la valeur : __refvalue

Une fois qu’on a une référence typée, il est possible de lire et/ou d’écrire la valeur référencée en utilisant le mot clé __refvalue. Il est visuellement assimilable à un appel de fonction à deux paramètres, dont le premier serait la TypedReference, et le second le type de la valeur référencée. En l’utilisant à droite d’une affectation, on lit la valeur, et en l’utilisant à gauche d’une affectation, on écrit la valeur. Assez troublant…

int i = 42;
TypedReference typedReference = __makeref(i);
int j = __refvalue (typedReference, int);
__refvalue (typedReference, int) = 24;

Encore une fois, il est possible de mapper son utilisation avec un opcode spécifique, refanyval :

int i = 42;
TypedReference typedReference = __makeref(i);

L_0000: ldc.i4.s 0x2a	/* push sur la pile d'un int32 = 42						*/
L_0002: stloc.0			/* sauvegarde dans la variable locale i					*/
L_0003: ldloca.s i		/* push sur la pile de l'adresse de i					*/
L_0005: mkrefany int32	/* push sur la pile de la référence typée				*/
L_000a: stloc.1			/* sauvegarde dans la variable locale typedReference	*/

int j = __refvalue (typedReference, int);

L_000b: ldloc.1			/* push sur la pile de la typedReference				*/
L_000c: refanyval int32 /* push sur la pile de l'adresse de la référence        */
L_0011: ldind.i4		/* déréférencement et push sur la pile de la valeur		*/
L_0012: stloc.2			/* sauvegarde dans la variable locale j					*/

__refvalue (typedReference, int) = 24;

L_0013: ldloc.1			/* push sur la pile de la typedReference				*/
L_0014: refanyval int32 /* push sur la pile de l'adresse de la référence        */
L_0019: ldc.i4.s 0x18	/* push sur la pile d'un int32 = 24						*/
L_001b: stind.i4		/* sauvegarde de la valeur à l'adresse de la référence  */

La méthode TypedReference.ToObject permet aussi de déréférencer la TypedReference et d’obtenir sa valeur, boxée.

Récupérer le type : __reftype

Enfin, il est possible de récupérer l’information de type associée à la TypeReference, en utilisant un dernier mot clé __reftype.

int i = 42;
TypedReference typedReference = __makeref(i);
Type type = __reftype(typedReference);

Là encore, on peut faire correspondre __reftype à l’opcode refanytype :

int i = 42;
TypedReference typedReference = __makeref(i);

L_0000: ldc.i4.s 0x2a	/* push sur la pile d'un int32 = 42						*/
L_0002: stloc.0			/* sauvegarde dans la variable locale i					*/
L_0003: ldloca.s i		/* push sur la pile de l'adresse de i					*/
L_0005: mkrefany int32	/* push sur la pile de la référence typée				*/
L_000a: stloc.1			/* sauvegarde dans la variable locale typedReference	*/

Type type = __reftype(typedReference);

L_000b: ldloc.1			/* push sur la pile de la typedReference				*/
L_000c: refanytype		/* push sur la pile du type token de la référence		*/
L_000e: call class Type::GetTypeFromHandle(RuntimeTypeHandle)
L_0013: stloc.2			/* récupération et sauvegarde du Type à partir du token */

Notons que la méthode statique TypedReference.GetTargetType est l’équivalent autorisé de __reftype, et qu’il existe aussi la méthode TypedReference.TargetTypeToken qui retourne le handle du type sous la forme d’un RuntimeTypeHandle. La version light, en somme.

Rien de très impressionnant ; d’ailleurs vous pouvez retourner sur youtube car la suite n’est pas mieux. Mais je persiste !

Un autre exemple : `GetValueDirect` et `SetValueDirect`

Je vous disais tout à l’heure que j’avais trouvé un exemple d’utilisation dans lequel on pouvait faire intervenir les TypedReference. Il s’agit de la lecture écriture des champs par réflexion, et plus particulièrement des champs de type valeur. Et encore plus particulièrement lorsqu’ils sont imbriqués.

Prenons pour exemple ce modèle simpliste :

public struct Person
{
	public Address Address;
}

public struct Address
{
	public City City;
}

public struct City
{
	public int ZipCode;
}

Il est important de bien noter que Person, Address, City et ZipCode sont des value types. Si on veut inspecter une instance de Person par réflexion, jusqu’à lire le ZipCode de son adresse, on va écrire quelque chose comme :

// On a une instance de Person
var p = new Person();
p.Address.City.ZipCode = 75000;

// On récupère les FieldInfo
var addressField = typeof(Person).GetField("Address");
var cityField = typeof(Address).GetField("City");
var zipCodeField = typeof(City).GetField("ZipCode");

// On chaine les appels à FieldInfo.GetValue pour inspecter la Person
// et lire la valeur du ZipCode
var zipCode =  (int)zipCodeField.GetValue(cityField.GetValue(addressField.GetValue(p)));

Ca fonctionne, mais le boxing a tué mon hourra. GetValue prend un object en argument, et retourne un object, alors qu’on travaille ici sur des types valeurs… En lisant la dernière ligne de droite à gauche :

p va être boxé pour être passé en paramètre à GetValue
addressField.GetValue va boxer la valeur du champ Address pour le retourner sous la forme d’un object
cityField.GetValue va boxer la valeur du champ City pour le retourner sous la forme d’un object
zipCodeField.GetValue va boxer la valeur du champ ZipCode pour le retourner sous la forme d’un object
Le cast en int effectue l’ultime et nécessaire unboxing

Pas terrible…

Heureusement, il existe sur FieldInfo la méthode GetValueDirect, qui prend en paramètre une TypedReference !

Si on peut directement récupérer une référence typée sur le ZipCode, on peut éviter quelques emboitages :

var p = new Person();
p.Address.City.ZipCode = 75000;
FieldInfo zipCodeField = typeof(City).GetField("ZipCode");
var zipCode = (int)zipCodeField.GetValueDirect(__makeref (p.Address.City));

Seulement, on change les contraintes, car la création de la référence typée de cette façon implique alors que l’on connaisse Address et City au design time. Qu’à cela ne tienne : il existe la méthode statique TypedReference.MakeTypedReference évoquée plus tôt, qui permet de construire une référence typée à partir d’une target et d’un tableau de FieldInfo correspondant à l’inspection désirée de l’espace mémoire réservé par p :

var p = new Person ();
p.Address.City.ZipCode = 75000;
var addressField = typeof (Person).GetField ("Address");
var cityField = typeof (Address).GetField ("City");
var zipCodeField = typeof (City).GetField ("ZipCode");

TypedReference r = TypedReference.MakeTypedReference (p, new[] {addressField, cityField});
var zipCode = (int) zipCodeField.GetValueDirect (r);

Dans ce cas précis, les performances mesurées sont environ 4 fois meilleures en utilisant GetValueDirect à la place de GetValue. Hourra.

Quant à l’écriture, nous n’avons même pas le luxe du choix, puisque chainer les SetValue ne peut en aucun cas modifier la personne, cette fonction retournant à chaque fois une copie des valeurs… Il faut donc nécessairement utiliser SetValueDirect et une TypedReference.

Conclusion

La conclusion, que je vous dois brève :

Ce qui n’est pas documenté ne doit pas être utilisé. En gros, tout ce qui est lié aux arglists est à oublier. En revanche, la création et la manipulation de TypedReference sans passer par tous les __mots __clés __moches n’est pas réprouvée. Notez simplement que TypedReference n’est pas CLS Compliant.

Posted in Articles Tagged: .NET, C#, CIL, Optimisation

Dégage, sale programmeur !

Romain Verdier — Mon, 29 Dec 2008 23:35:29 +0000

Et ouais, être développeur lorsqu’on a plus de 30 ans en France, c’est pire que d’être caissier à 40 ans. La plupart des gens qui passent 90% de leur temps à programmer vont s’arranger pour qu’on les voit comme des ingénieurs d’études, des experts techniques, des chefs de projets, des architectes solution, des consultants, etc. Le top, quand on est un pauvre prestataire d’une SSII en mission pour une banque, et que l’on passe ses journées à coder, c’est de raconter à tout le monde qu’on est INGENIEUR DANS LA FINANCE. Oui oui.

C’est assez terrible, mais il semblerait qu’on n’y puisse pas grand chose.

La première observation, c’est que le phénomène est assez localisé. Ou plutôt : le phénomène n’est pas généralisé. En France, dès les études, on explique qu’il y a les développeurs (berk), et les chefs (ouais).

Bon, les enfants, si vous avez été admis chez SUPIMAG, c’est pas pour finir développeur. En sortant de notre établissement, espérez être chef de projet junior (à la tête de 5 développeurs, 52K€, pendant 6 à 12 mois), puis, évidemment directeur de projet (1200 développeurs à vos pieds, 420K€ + iPhone + bonus)

Et ensuite, même si on se fout de votre gueule lors des premiers entretiens, c’est trop tard : vous ne voulez plus, vous ne pouvez plus être développeur. On pourrait vous confondre avec l’admin réseau (BTS Informatique et Réseaux pour l’Industrie et les Services Techniques, 23K€, Nokia 3310 pour les astreintes).

Aux Etats-Unis, par exemple, et sans doute ailleurs, ça ne fonctionne pas comme ça. Il y a différents métiers. Développeur, c’est un métier. Manager, c’est un autre métier. Le développeur programme, et le manager gère. Il est tout à fait possible de rester programmeur lorsqu’on devient papa. On n’est pas pris pour un con, juste pour un programmeur senior, payé et reconnu comme tel. Un professionnel ayant fait un choix de carrière plutôt qu’un autre, en somme. Il n’y a pas une hiérarchie dans laquelle le programmeur est en bas de l’échelle, il y a juste différents métiers dont les exercices sont nécessaires à la réalisation des projets informatiques.

Tant qu’on ne comprendra pas ça ici, on continuera à subir les rires bruyants des gros blaireaux qui parlent de pissage-de-code-lol.

Gens, vous vous trompez.

Le développement, ou l’ingénierie logicielle si on veut élargir un peu, est une discipline complexe, qui requiert un cerveau. Un développeur digne de ce nom est une personne capable de réfléchir, de conceptualiser, de comprendre. C’est une personne capable de travailler en équipe, de communiquer efficacement, de s’organiser. C’est une personne qui ne peut pas se reposer éternellement sur ses acquis. C’est aussi une personne qui doit produire, et qui peut difficilement tricher. Programmer est un métier à la fois compliqué et passionnant, dont on peut même penser qu’il demande du talent. En fait, c’est probablement l’un des métiers les plus exigeants et intelligents qui soient.

Il est presque incompréhensible qu’on en soit arrivé à trouver ça péjoratif, et que la programmation ait été reléguée au rang de tâche honteuse.

Programmeur : n.m. Celui dont le métier est de rédiger des programmes informatiques. Le plus souvent, jeune diplômé, ou chef de projet raté. Syn. loser. Ex. Tu crains comme un programmeur.

Première hypothèse : Romain, t’es un crétin doublé d’un parano : personne n’a cette sale image des développeurs. Deuxième hypothèse – très personnelle et probablement très discutable : tout le monde n’est pas né pour être programmeur. Et tant mieux, devrais-je ajouter : il serait assez triste de rêver du contraire. Cependant, il y a un besoin de programmeurs, en France comme ailleurs, et donc, on obtient fatalement une armée de développeurs-malgré-eux. Ni particulièrement doués ni particulièrement motivés, il se retrouvent à devoir maintenir des applications plus ou moins monstrueuses, sans vraiment comprendre ce qu’ils font et sans avoir envie d’ailleurs d’en comprendre plus. Développer, pfiou, c’est finalement un peu relou, hein. Vivement que je puisse moi aussi passer mes journées sur Powerpoint.

Ce que je veux dire, c’est que dans le fond, il y a peu de personnes qui savent ce qu’est la programmation. Parmi les programmeurs, les chefs, les recruteurs, les profs, les chats, ma mère. Moi, plus par fausse modestie que pour paraphraser Socrate, j’ai découvert il n’y a pas si longtemps que je ne savais pas vraiment ce qu’était la programmation.

Bon, j’exagère un peu pour que vous souriez, mais au delà de la simplification volontairement naïve et de la provocation facile, je crois qu’il y a un peu de vrai. Quand la Masse se met d’accord sur une définition faussée du métier de programmeur, les choses sont vite réglées. A côté de ça, il y a des développeurs “qui ont goûté au sang” (© Jb) et qui ont du mal à revenir aux Taillefine “Pruneau” 0%. Tant qu’à faire, ne confondez pas tout le monde et choisissez bien votre audience le jour où vous voulez expliquer que vous aimez programmer, ou pire, que vous êtes capable d’en tirer une certaine fierté.

Au fait, ça existe les architectes qui écrivent juste les prototypes des méthodes et qui laissent l’implémentation aux programmeurs ?

Posted in Posts Tagged: Opinion

Cecil.Decompiler : Un décompilateur .NET OpenSource

Romain Verdier — Tue, 16 Dec 2008 22:23:30 +0000

Jean-Baptiste Evain vient de l’annoncer sur son blog : il travaille actuellement sur un nouveau projet particulièrement ambitieux appelé Cecil.Decompiler. Comme son nom l’indique, il s’agit d’un décompilateur .NET basé sur Mono.Cecil (du même auteur) qui permettait déjà de manipuler le langage intermédiaire du CLR.

Quelques jours avant l’annonce officielle, Jb a organisé un Code Camp en Ardèche (près de Lyon) en invitant quelques personnes à travailler avec lui sur ce decompiler. L’idée était avant tout de passer un bon moment, de ~~faire avancer~~ découvrir le projet, mais aussi d’intéresser et d’encourager d’éventuels futurs contributeurs à rejoindre l’initiative.

Comme j’ai eu la chance de faire partie des petits privilégiés, je vais essayer de vous livrer mes impressions à chaud.

Déjà, belle surprise en recevant le mail d’invitation de Jb… Nous ne nous étions croisé qu’une soirée, à Paris, lorsqu’il était venu présenter Mono en novembre pour une de nos réunions ALT.NET. Dans un milieu où le copinage reste bien présent, ce genre de proposition dénote bien une certaine ouverture d’esprit, et un fort degré de coolitude. Merci. Robert Pickering faisait aussi partie des invités mais à part lui (et Jb, donc) je ne connaissais personne. Ce fut l’occasion de faire la connaissance de Patrice Lamarche, Mathieu Szablowski, Vincent Bourdon, et Sébastien Lebreton (auteur de réflexil). Sept personnes en tout ; soit un petit comité.

Je vous avouerai que j’étais un peu impressionné à l’idée de devoir rejoindre tout ce beau monde pour travailler sur un projet de cette envergure, dont la complexité moyenne dépasse quand même celle d’une application de gestion classique… Mais l’ambiance était excellente d’une part, et le sujet carrément intéressant d’autre part.

Ca ne suffit pas pour faire oublier qu’on est en train de faire du pair programming avec un mec de l’équipe Mono, mais ça aide un peu. En tout cas, ça fait vraiment plaisir de participer à un projet aussi motivant, avec des gens dont la simple proximité rend moins con. J’aurais aimé pouvoir travailler en pair avec tout le monde, mais j’ai principalement codé avec Jb et Rob. Et tout seul aussi, hein. Je n’ai pas envie de rentrer dans les détails techniques aujourd’hui, mais en gros, j’ai principalement travaillé sur la partie “décompilation C#”, et plus particulièrement sur les étapes de transformation de l’arbre syntaxique visant à faire apparaitre les structures de haut niveau du langage.

Le decompiler lit le code intermédiaire, en infère un Control Flow Graph, puis un AST assez brut dans lequel, par exemple, toutes les pre/post-tested loops sont modélisées sous la forme de statements while/do-while. Selon le langage, et selon la version du langage, il faudra ensuite exécuter une série d’analyses et de transformations sur cet arbre afin de reconnaitre les constructions spécifiques. Par exemple, et au hasard, le foreach.

Dans un vieux post, j’expliquais que le foreach en C# était syntaxiquement équivalent à :

IEnumerator enumerator = jambons.GetEnumerator();
try
{
	while( enumerator.MoveNext())
	{
		Jambon jambon = enumerator.Current;
		// Manger le jambon, miam, etc.
	}
}
finally
{
	IDisposable disposableEnumerator = enumerator as IDisposable;
	if(disposableEnumerator != null)
	{
		disposableEnumerator.Dispose();
	}
}

C’est donc le pattern qu’il faut identifier dans l’arbre, à quelques subtilités près. Ca m’a pris 3 bons jours, et c’est loin d’être terminé si on veut gérer tous les edge cases, allez donc savoir pourquoi. J’ai aussi travaillé avec Jb sur une implémentation sympa d’un “pattern matching du pauvre” en C#, joyeusement supprimée depuis… On cherche quelque chose de mieux. Mais ça permettait d’écrire des trucs rigolos du genre :

// Création du pattern
var matcher = Pattern.Match()
					 .Is()
                     .Select(mie => mie.Method)
                     .Is()
                     .Tag(() => method_key, mre => mre.Method)
                     .Tag(() => target_key, mre => mre.Target);

// Compilation du pattern matcher pour récupérer un delegate qui pourra être mis en cache
// et invoqué avec de bonnes performances
var methodInvocationMatcher = matcher.Compile> ();

// Exécution du pattern matching : on obtient un MatchResult
var result = Pattern.Run (MethodInvocationMatcher, expression);

// On peut maintenant, en cas de succès, travailler avec les valeurs qui ont été tagguée
// lors du pattern matching, si elles ont été trouvées
if (result.Success)
{
	Expression targetExpression;
    if (result.TryGetValue(target_key, out targetExpression))
    {
		// ...
	}

	MethodReference methodReference;
	if (result.TryGetValue(method_key, out methodReference))
	{
		// ...
	}
}

Le code du matcher pouvait être généré dynamiquement via System.Reflection.Emit, puis compilé pour obtenir un delegate capable d’être exécuté sans ruiner les perfs. Ca peut vous rappeler quelque chose… mais l’idée n’était pas de moi !

J’ai également eu l’opportunité de travailler avec Rob pour réaliser une version F# du matcher capable de détecter les foreach à titre d’essai. Pas vraiment l’initiation idéale à F# pour un profane comme moi, mais heureusement Rob a gardé le clavier durant la session. Ce fut pour moi l’occasion d’avoir un bon aperçu de la puissance du langage en matière de pattern matching et de tester rapidement pour la première fois l’intérop C#/F#.

Le projet en lui-même est à mon sens prometteur. Ce n’est pas juste un Reflector-bis. Il s’agit d’un framework de décompilation, libre et open source, qui peut être embarqué n’importe où. Ca ouvre pas mal de perspectives pour ceux qui travaillent sur des outils d’analyse statique de code par exemple. Jason Bock, auteur de CIL Programming avec lequel j’ai été méchant par le passé, va même jusqu’à trouver Cecil.Decompiler et sa licence MIT/X11 rassurants dans la mesure où la visibilité sur le devenir de Reflector est compromise.

Je ne suis pas sûr de vouloir crier hourra pour ça, mais ce dont je suis sûr, c’est que pouvoir disposer d’un décompilateur .NET open source, managé, qui repose sur une base solide, c’est tout bon. Si on considère en plus que Sébastien est déjà lancé à fond sur la réalisation d’une interface pour exploiter Cecil.Decompiler, dont le modèle d’extensibilité devrait être plus souple que celui de Reflector, c’est encore plus alléchant.

Quoi qu’il en soit, le decompiler en est à ses débuts. Il reste vraiment beaucoup de choses à faire, et ce à plusieurs niveaux :

Core
Support des langages : C#, VB, F#, etc.
Interface, plugins

Mais au moins, vous savez à présent que le projet existe.

Posted in Posts Tagged: .NET, Annonce, C#, Cecil.Decompiler, Expression Tree