Blog de Matthieu MEZIL » IL

Bien comprendre les bases de LINQ To Objects

Matthieu MEZIL — Mon, 22 Oct 2007 07:39:50 +0000

Frédéric Mélantois vient de publier son article « Bien comprendre les bases de LINQ To Objects »

Modification d’assemblage et injection de code C# / VB.NET à la volée

Matthieu MEZIL — Mon, 17 Sep 2007 07:23:07 +0000

Je vous avez parlé précédemment de Sébastien Lebreton et de son add-in pour reflector : Reflexil.
Il vient de publier un article sur THB sur la modification d’assembly (désolé mais j’ai du mal avec assemblage) et l’injection de code C# / VB .NET à la volée.

Reflexil 0.3

Matthieu MEZIL — Thu, 30 Aug 2007 12:04:53 +0000

Je viens de découvrir via Fred via Gaël Covain Reflexil.
Reflexil est un add-in reflector qui permet de créer ou de modifier le code IL des méthodes d’un assembly puis de sauvegarder les modifications.
Sébastien lebreton (son développeur) a sorti la version 0.4 hier.
Je viens de la récupérer et vous en direz plus après l’avoir un peu plus utilisée. Ma première impression est très positive.

Optimisation de l’IL généré par le compilateur

Matthieu MEZIL — Thu, 23 Aug 2007 07:28:02 +0000

Dans le cas d’une méthode (non statique) qui renvoit this, l’IL fait un pop même s’il a besoin de l’instance juste derrière :

private static void Main(string[] args)
{
StringBuilder sb = new StringBuilder();
sb.Append("azerty");
Console.WriteLine(sb);
}

donne l’IL suivant :

.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
.maxstack 2
.locals init (
[0] class [mscorlib]System.Text.StringBuilder sb)
L_0000: nop
L_0001: newobj instance void [mscorlib]System.Text.StringBuilder::.ctor()
L_0006: stloc.0
L_0007: ldloc.0
L_0008: ldstr "azerty"
L_000d: callvirt instance class [mscorlib]System.Text.StringBuilder [mscorlib]System.Text.StringBuilder::Append(string)
L_0012: pop
L_0013: ldloc.0
L_0014: call void [mscorlib]System.Console::WriteLine(object)
L_0019: nop
L_001a: ret
}

alors qu’il pourrait être optimisé comme suit :

.method private hidebysig static void Main(string[] args) cil managed
{
.entrypoint
.maxstack 2
L_0001: newobj instance void [mscorlib]System.Text.StringBuilder::.ctor()
L_0008: ldstr "azerty"
L_000d: callvirt instance class [mscorlib]System.Text.StringBuilder [mscorlib]System.Text.StringBuilder::Append(string)
L_0014: call void [mscorlib]System.Console::WriteLine(object)
L_001a: ret
}

Dans l’exemple, il est dommage de décharger la pile de l’instance de StringBuilder pour remettre la même.

Petite précision tout de même, contrairement à mon post précédent sur les optimisations du compilateur, dans ce cas, le compilateur est obligé de faire cela. En effet, il faudrait sinon qu’il teste toutes les méthodes qui retourne un objet du même type que l’instance sur laquelle elles s’appliquent pour s’assurer que c’est bien this qui est retourné.

L’IL généré par le compilateur optimisable

Matthieu MEZIL — Tue, 14 Aug 2007 07:36:32 +0000

L’IL généré par le compilateur peut être réduit.

Prenons un exemple tout simple :

public static string Test(string s)
{
return s.ToUpper();
}

L’IL généré par le compilateur est le suivant :

.method public hidebysig static string Test(string s) cil managed
{
.maxstack 1
.locals init (
[0] string CS$1$0000)
L_0000: nop
L_0001: ldarg.0
L_0002: callvirt instance string [mscorlib]System.String::ToUpper()
L_0007: stloc.0
L_0008: br.s L_000a
L_000a: ldloc.0
L_000b: ret
}

Sauf subtilité qui m’aurait échappée, l’IL suivant fait la même chose :

.method public hidebysig static string Test(string s) cil managed
{
.maxstack 1
L_0001: ldarg.0
L_0002: callvirt instance string [mscorlib]System.String::ToUpper()
L_000b: ret
}

Prenons un autre exemple :

public static void Test(string s1, string s2)
{
if (s1 == null || s2 == null)
throw new ArgumentNullException();
}

L’IL généré est le suivant :

.method public hidebysig static void Test(string s1, string s2) cil managed
{
.maxstack 2
.locals init (
[0] bool CS$4$0000)
L_0000: nop
L_0001: ldarg.0
L_0002: brfalse.s L_000d
L_0004: ldarg.1
L_0005: ldnull
L_0006: ceq
L_0008: ldc.i4.0
L_0009: ceq
L_000b: br.s L_000e
L_000d: ldc.i4.0
L_000e: stloc.0
L_000f: ldloc.0
L_0010: brtrue.s L_0018
L_0012: newobj instance void [mscorlib]System.ArgumentNullException::.ctor()
L_0017: throw
L_0018: ret
}

alors qu’on aurait pu simplifier par

.method public hidebysig static void Test(string s1, string s2) cil managed
{
.maxstack 1
L_0001: ldarg.0
L_0002: brfalse.s L_0012
L_0004: ldarg.1
L_0005: brtrue.s L_0018
L_0012: newobj instance void [mscorlib]System.ArgumentNullException::.ctor()
L_0017: throw
L_0018: ret
}

internal ET protected

Matthieu MEZIL — Fri, 17 Aug 2007 07:44:22 +0000

Quand une méthode est définie internal protected, c’est un OU qui est fait (idem pour protected internal). Par conséquent, cette méthode sera utilisable depuis une classe fille ou une classe de l’assembly.
En C#, il n’y a pas de internal ET protected. Pourtant, cette possibilité existe au niveau de l’IL.
En effet, quand on crée une méthode à la volée via MethodBuilder, on peut définir la méthode Private, FamANDAssem, Assembly (internal), Family (protected), FamORAssem ou Public.

classe statique, une spécificité C#

Matthieu MEZIL — Fri, 17 Aug 2007 07:55:30 +0000

J’avais déjà remarqué que la notion de classe statique n’existait pas en VB.
Aussi je ne suis pas surpris de voir que cette notion n’est exploitée que par le compilateur et n’existe pas non plus en IL. Pour l’IL, une classe statique est une classe abstraite.
Il y a quand même une différence notable entre une classe statique et une classe abstraite dans l’IL.
Dans le cas d’une classe abtraite, on a un constructeur par défaut protected et un constructeur statique. Dans le cas d’une classe statique, on n’a que le constructeur statique.