Convertir implicitement des delegates ayant la même signature
Hier soir, je tombe sur un tweet de Krzysztof Koźmic :
Do I care if it’s Predicate<int> or Func<int>? No, than why won’t C# compiler just live me alone and pick whatever it needs? I DONT CARE
Et là je me dis HAHA LOL MAIS N’IMPORTE QUOI Predicate<int> et Func<int> c’est très différent voilà une bonne occasion pour moi qui ne suis rien de reprendre gratuitement un des contributeurs principaux de Castle sur une étourderie. Et je lui fais remarquer, en gros :
Tout ce que vous n’avez pas besoin de savoir au sujet du mot clé event
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 !)
Si les types étaient des animaux, TypedReference serait un ornithorynque
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.
(more…)
Introduction à Mono.Cecil : Implémenter INotifyPropertyChanged
Vous allez probablement m’en vouloir à force, mais j’ai décidé de continuer mes expériences autour d’INotifyPropertyChanged. Cette fois-ci, en utilisant Mono.Cecil pour faire un peu d’IL rewriting. Où comment tisser un aspect sans utiliser de framework AOP. Comparée à celle basée sur PostSharp.Laos, cette solution a un inconvénient majeur : elle est plus roots.
En revanche, aucune autre méthode à ma connaissance ne permet d’obtenir un tissage aussi fin. Par fin, j’entends spécifique, propre, non pollué par le code que génèrent les outils d’AOP classiques pour supporter les mécanismes d’interception. Donc les performances seront à la clé puisqu’une fois l’assembly retravaillé avec Cecil, il ne sera plus possible de faire la différence entre son code IL et celui qui aurait été généré si nous avions implémenté INotifyPropertyChanged à la main. Le développement aura juste été un peu plus cher…
Utiliser l’AOP avec PostSharp pour implémenter INotifyPropertyChanged
J’ai ce billet dans mes drafts depuis un moment, et il serait peut-être bon de l’en sortir avant qu’il ne soit trop tard… Dans un post récent, je parlais de l’interface INotifyPropertyChanged, en donnant un exemple d’implémentation basée sur les lambda expressions et les expression trees qui permettait d’obtenir une solution fortement typée.
L’AOP peut également être une solution, et peut-être même le meilleur compromis pour peu que l’on en tire partie correctement. Suite à un commentaire de Jb, j’ai essayé de voir ce que pouvait donner l’utilisation d’un tisseur statique comme PostSharp dans ce cas précis.
(more…)
Continuer l’optimisation avec la Lightweight Code Generation (LCG)
Cet article est un complément du précédent. Vous pouviez y lire dans la conclusion :
Nous nous sommes contentés d’évoquer la solution d’optimisation impliquant la génération de code IL. Dans le contexte de la problématique discutée, elle n’offrait aucun avantage par rapport à celle que nous avons exposée. Pire, elle imposait une étape inutile. Toutefois, certains besoins plus complexes dépassent le cadre des invocations dynamiques de méthodes et peuvent tout de même être adressés efficacement en recourant à la génération de bytecode.
S’il existe des scénarios dans lesquels le recourt à la LCG est inutile voire pénalisant, il n’y a parfois aucune autre alternative lorsqu’il s’agit de mettre en place une solution où les performances sont aussi importantes que la dynamicité.
Vous ne trouverez pas ici un tutorial sur l’utilisation de Reflection.Emit, mais plutôt un exemple d’utilisation de cette technique pour répondre de façon optimale à un besoin bien spécifique. Nous essaierons en parallèle de faire ressortir quelques guidelines relatives à l’usage de la LCG.
(more…)
Optimisation des invocations dynamiques de méthodes en C#
Je travaille actuellement en tant que consultant .NET sur un projet d’une certaine taille.
Travailler sur un projet d’une certaine taille ne signifie pas forcément que l’on travaille sur un projet intéressant, mais ça augmente sensiblement les chances de rencontrer de nouveaux problèmes. Il n’est pas question aujourd’hui de définir ce qu’est un projet d’une certaine taille, ni même de démontrer le postulat précédent ; il s’agit plutôt de parler d’une des dernières problématiques auxquelles j’ai dû faire face :
Comment éviter que les invocations dynamiques de méthodes via la réflexion rendent les performances d’une application ou d’un module catastrophiques ?
Réponse : En minimisant l’utilisation de la réflexion. C’est ce que je vais tenter de développer à travers un exemple directement inspiré du projet réel, quoiqu’adapté pour les besoins de l’article. Le langage utilisé sera C# 3.0, mais rien n’empêche d’utiliser C# 2.0.
(more…)
Le mot clé yield et les itérateurs en C#
Cet article est un peu particulier. D’une part, il s’agit de mon premier vrai post, et d’autre part, j’ai choisi de traiter en détail un sujet pas forcément nouveau et surtout très spécifique : les itérateurs et le mot clé yield de C#.
C’est pas ma faute, tout le monde (ou presque) s’en fout, ou ne sait pas qu’il existe.
Pourtant, ce mécanisme n’est pas seulement troublant, il est également puissant lorsqu’on l’utilise en maitrisant son fonctionnement. S’il me fallait trouver un exemple, je parlerais de l’implémentation principale de LINQ, basée sur les itérateurs et le mot clé yield.
yield. Par contre, si vous cherchez à comprendre le fonctionnement réel des itérateurs, il peut s’agir d’un bon point de départ. C’est un peu le parallèle que l’on pourrait faire entre la MSDN et le livre des spécifications de C#.
Articles
Codingly 
5 comments