Dot.Blog

C#, XAML, Xamarin, UWP/Android/iOS

Contourner le problème de l'appel d'une méthode virtuelle dans un constructeur

Ce problème est source de bogues bien sournois. J'ai déjà eu l'occasion de vous en parler dans un billet cet été (Appel d'un membre virtuel dans le constructeur ou "quand C# devient vicieux". A lire absolument...), la conclusion était qu'il ne faut tout simplement pas utiliser cette construction dangereuse. Je proposais alors de déplacer toutes les initialisations dans le constructeur de la classe parent, mais bien entendu cela n'est pas applicable tout le temps (sinon à quoi servirait l'héritage).

Dès lors comment proposer une méthode fiable et systématique pour contourner le problème proprement ?

Rappel

Je renvoie le lecteur au billet que j'évoque en introduction pour éviter de me répéter, le problème posé y est clairement démontré. Pour les paresseux du clic, voici en gros le résumé de la situation : L'appel d'une méthode virtuelle dans le constructeur d'une classe est fortement déconseillé. La raison : lorsque qu'une instance d'une classe dérivée est créée elle commence par appeler le constructeur de son parent (et ainsi de suite en cascade remontante). Si ce constructeur parent appelle une méthode virtuelle overridée dans la classe enfant, le problème est que l'instance enfant elle-même n'est pas encore initialisée, l'initialisation se trouvant encore dans le code du constructeur parent. Et cela, comme vous pouvez l'imaginer, ça sent le bug !

Une première solution

La seule et unique solution propre est donc de s'interdire d'appeler des méthodes virtuelles dans un constructeur. Et je serai même plus extrémiste : il faut s'interdire d'appeler toute méthode dans le constructeur d'une classe, tout simplement parce qu'une méthode non virtuelle, allez savoir, peut, au gréé des changements d'un code, devenir virtuelle un jour. Ce n'est pas quelque chose de souhaitable d'un pur point de vue méthodologique, mais nous savons tous qu'entre la théorie et la pratique il y a un monde...

Tout cela est bien joli mais s'il y a des appels à des méthodes c'est qu'elles servent à quelque chose, s'en passer totalement semble pour le coup tellement extrême qu'on se demande si ça vaut encore le coup de développper ! Bien entendu il existe une façon de contourner le problème : il suffit de créer une méthode publique "Init()" qui elle peut faire ce qu'elle veut. Charge à celui qui créé l'instance d'appeler dans la foulée cette dernière pour compléter l'initialisation de l'objet.

Le code suivant montre une telle construction :

 // Classe Parent
    public class Parent2
    {
        public Parent2(int valeur)
        {
            // MethodeVirtuelle();
        }
 
        public virtual void Init()
        {
            MethodeVirtuelle();
        }
 
        public virtual void MethodeVirtuelle()
        { }
    }
 
    // Classe dérivée
    public class Enfant2 : Parent2
    {
        private int val;
 
        public Enfant2(int valeur)
            : base(valeur)
        {
            val = valeur;
        }
 
        public override void MethodeVirtuelle()
        {
            Console.WriteLine("Classe Enfant2. champ val = " + val);
        }
    }

La méthode virtuelle est appelée dans Init() et le constructeur de la classe de base n'appelle plus aucune méthode.

C'est bien. Mais cela complique un peu l'utilisation des classes. En effet, désormais, pour créer une instance de la classe Enfant2 il faut procéder comme suit :

 // Méthode 2 : avec init séparé
 var enfant2 = new Enfant2(10);
 enfant2.Init(); // affichera 10

Et là, même si nous avons réglé un problème de conception essentiel, côté pratique nous sommes loin du compte ! Le pire c'est bien entendu que nous obligeons les utilisateurs de la classe Enfant2 à "penser à appeler Init()". Ce n'est pas tant l'appel à Init() qui est gênant que le fait qu'il faut penser à le faire ... Et nous savons tous que plus il y a de détails de ce genre à se souvenir pour faire marcher un code, plus le risque de bug augmente.

Conceptuellement, c'est propre, au niveau design c'est à fuir...

Faut-il donc choisir entre peste et choléra sans aucun espoir de se sortir de cette triste alternative ? Non. Nous pouvons faire un peu mieux et rendre tout cela transparent notamment en transférant à la classe enfant la responsabilité de s'initialiser correctement sans que l'utilisateur de cette classe ne soit obligé de penser à quoi que ce soit.

La méthode de la Factory

Il faut absolument utiliser la méthode de l'init séparé, cela est incontournable. Mais il faut tout aussi fermement éviter de rendre l'utilisation de la classe source de bugs. Voici nos contraintes, il va falloir faire avec.

La solution consiste à modifier légèrement l'approche. Nous allons fournir une méthode de classe (méthode statique) permettant de créer des instances de la classe Enfant2, charge à cette méthode appartenant à Enfant2 de faire l'intialisation correctement. Et pour éviter toute "bavure" nous allons cacher le constructeur de Enfant2. Dès lors nous aurons mis en place une Factory (très simple) capable de fabriquer des instances de Enfant2 correctement initialisées, en une seule opération et dans le respect du non appel des méthodes virtuelles dans les constructeurs... ouf !

C'est cette solution que montre le code qui suit (Parent3 et Enfant3 étant les nouvelles classes) :

    // Classe Parent
    public class Parent3
    {
        public Parent3(int valeur)
        {
            // MethodeVirtuelle();
        }
 
        public virtual void Init()
        {
            MethodeVirtuelle();
        }
 
        public virtual void MethodeVirtuelle()
        { }
    }
 
    // Classe dérivée
    public class Enfant3 : Parent3
    {
        private int val;
 
        public static Enfant3 CreerInstance(int valeur)
        {
            var enfant3 = new Enfant3(valeur);
            enfant3.Init();
            return enfant3;
        }
 
        protected Enfant3(int valeur)
            : base(valeur)
        {
            val = valeur;
        }
 
        public override void MethodeVirtuelle()
        {
            Console.WriteLine("Classe Enfant3. champ val = " + val);
        }
    }

La création d'une instance de Enfant3 s'effectue dès lors comme suit :

 var enfant3 = Enfant3.CreerInstance(10);

C'est simple, sans risque d'erreur (impossible de créer une instance autrement), et nous respectons l'interdiction des appels virtuels dans le constructeur sans nous priver des méthodes virtuelles lors de l'initialisation d'un objet. De plus la responsabilité de la totalité de l'action est transférée à la classe enfant ce qui centralise toute la connaissance de cette dernière en un seul point.

Dans une grosse librairie de code on peut se permettre de déconnecter la Factory des classes en proposant directement une ou plusieurs abstraites qui sont les seuls points d'accès pour créer des instances. Toutefois je vous conseille de laisser malgré tout les Factory "locales" dans chaque classe. Cela évite d'éparpiller le code et si un jour une classe enfant est modifiée au point que son initialisation le soit aussi, il n'y aura pas à penser à faire des vérifications dans le code de la Factory séparée. De fait une Factory centrale ne peut être vue que comme un moyen de regrouper les Factories locales, sans pour autant se passer de ces dernières ou en modifier le rôle.

Conclusion

Peut-on aller encore plus loin ? Peut-on procéder d'une autre façon pour satisfaire toutes les exigences de la situation ? Je ne doute pas qu'une autre voie puisse exister, pourquoi pas plus élégante. Encore faut-il la découvrir. C'est comme en montagne, une fois qu'une voie a été découverte pour atteindre le sommet plus facilement ça semble une évidence, mais combien ont du renoncer au sommet avant que le découvreur de la fameuse voie ne trace le chemin ?

Saurez-vous être ce premier de cordée génial et découvrir une voie alternative à la solution de la Factory ? Si tel est le cas, n'oubliez pas de laisser un commentaire !

Dans tous les cas : Stay Tuned !

Et pour jouer avec le code, le projet de test VS 2008 : VirtualInCtor.zip (5,99 kb)

Silverlight 2 for Mobile : Une CTP pour le 1er timestre 2009 !

Il y a encore quelques jours je vous informais de la mise à jour française des outils pour Silverlight 2 et j'en profitais pour rappeler qu'il s'agit d'une solution multi plateforme unique en son genre. Une voix s'est fait entendre pour rappeler que sous Linux ce n'est pas encore au niveau de SL 2, c'est vrai. Mais preuve de ce dynamisme multi plateforme c'est maintenant au tour de Silverlight pour Mobile d'être annoncé par MS !

Et l'avancée est de taille puisque il n'y aura pas besoin de modifier son code pour qu'une application SL puisse tourner sur Mobile, même si elle utilise des vidéos. C'est incroyable quand on sait que sur un Mobile la place est réduite pour arriver à y faire entrer le framework .NET, même la version allégée de SL. Prouesse technique donc. Et encore plus d'ouverture pour les développeurs.

Autre annonce de taille, Silverlight est pour l'instant une technologie "navigateur", mais il semble que les équipes en charge de ce produit désire le faire évoluer en quelque chose de stand-alone, hors de tout navigateur. Une plateforme .NET multi OS fonctionnant directement sur Mac, PC, Linux, Mobile ? Il est vrai que techniquement il "suffit" de se passer du browser. Mais quelle perspective ! Avec WCF et les sockets pour la communication la panoplie semble alléchante.

Pour ce qui est des plateformes mobiles supportées, on retrouve bien entendu Windows Mobile 6.x. Là aussi, bien que les choses ne soient pas arrêtées, il semblerait que le support Windows Embedded CE soit sous le coude des développeurs SL...

Si vous voulez en savoir plus je vous conseille la video de "Silverlight 2 for Mobile" enregistrée aux dernières PDC et déjà diffusée sur le célèbre Channel 9 !

Obama for President !

Il est  5h50 du matin... 338 grands électeurs contre 155, la victoire de Obama est large et sans discussion. McCain a, selon la tradition, appelé le gagnant et fait en premier son discours annonçant et reconnaissant la victoire de Obama. Il est 6h01 maintenant (je relis ce billet) et Obama s'exprime à la tribune.

Sans bavure, sans discussion. Obama devient le premier président noir des USA.

L'instant est historique et démontre la capacité du peuple américain à se dépasser, à bouleverser les clivages les plus infranchissables. Autant l'élection de GW Bush fut une erreur déprimante, autant celle de Obama montre au monde la voie d'une démocratie vivante.

A quand un président se prénomant Mohamed ou Fet-Nat en France ? Serons-nous capable, au-delà de notre fâcheuse habitude de donneurs de leçons, de prouver que nous sommes nous aussi un grand peuple ? ...

Plus loin que le symbole humaniste et l'espoir qu'il soulève, notons sur le plan strictement politique qu'au moment où nous avons à peine élu un président à la solde de Bush et voulant, entre autres choses, privatiser notre système social, les USA, le pays le plus libéral et le plus capitaliste du monde, viennent d'élire un noir de gauche qui veut instaurer un système de sécurité sociale universel...

Il y a de quoi se sentir petit. Tout petit. Il paraît qu'on a le président qu'on mérite. ça fiche un coup.

Mais les américains viennent de montrer que tout est possible, Yes We Can ! doit devenir notre slogan à nous aussi. Balayons les guignols qui nous gouvernent, autant que la fausse gauche caviar qui veut prendre sa place, osons avancer vers plus d'humanisme, vers plus de Fraternité et d'Egalité, et en ces temps où le sénat vient de voter la riposte graduée consistant à appliquer une peine collective à toute une famille sans qu'aucun juge n'intervienne, donc surtout osons protéger la Liberté.

La réalisation du vrai rêve américain c'est l'élection de Obama. Sachons copier ce qu'elle a de meilleure au lieu de vouloir appliquer ce qu'elle a de pire.

La démocratie est ce matin victorieuse. L'amérique est victorieuse. Elle peut être fière d'elle-même. Que cela puisse nous inspirer...

 

Bonne nouvelle, Mise à jour en FR des outils Silverlight ! (et autres infos)

Silverlight, le truc le plus exitant avec LINQ dans toutes les technos MS du moment... La version 2.0 qui est sortie depuis quelques semaines est la première qui propose un CLR portable fonctionnant sous Mac ou Linux avec l'adoption de C# au lieu de JavaScript comme langage de programmation. Ce n'est pas la seule nouveauté de SL 2 (voir mes billets à ce sujet) mais c'est essentiel et c'est ce qui rend la V 2 réellement intéressante.

Les outils pour gérer SL 2.0 étaient déjà dispos depuis quelques temps mais en US seulement et les patches ne pouvaient pas passer sur les versions FR.

ça y est ! Microsoft de vient de mettre de ligne les outils SL 2 pour Visual Studio FR et aussi (et surtout) le SP1 de Blend 2 FR !

Si vous ne possédez pas Blend, achetez-le, c'est le seul vrai moyen de développer sérieusement sous WPF et Silverlight (en tandeme avec Visual Studio). Je vous conseille aussi au passage Expression Design (plus simple à prendre en main que Illustrator) ainsi que l'excellent Xaml 3D de Electric Rain (ou son grand frère Swift 3D), des softs de création 3D que j'adore (j'aurai des choses à vous montrer dans quelques temps). SL 2 ne gère pas encore la 3D come WPF mais il existe un projet CodePlex d'un tel moteur qui est pas mal avancé (projet Balder)

Pour ce qui est des Tools Visual Studio avec le SDK c'est ici : http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=c22d6a7b-546f-4407-8ef6-d60c8ee221ed

Pour la mise à jour de Blend 2 SP1 c'est ici : http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=eb9b5c48-ba2b-4c39-a1c3-135c60bbbe66

A noter que les outils SL 2 peuvent être installés sur VS Express Web Edition pour obenir une solution totalement gratuite de dev sous SL 2 !

Eclatez-vous bien avec Silverlight, et Stay Tuned !

Un utilitaire en or (Launchy)

Juste un petit billet pour vous signaler l'existence d'un petit utilitaire WIndows génial dont je ne plus me passer, sous XP comme sous Vista.

C'est Launchy. Alt-Barre d'espace, taper une lettre ou deux et hop! vous lancez vos applications et même vos liens internet favoris (paramétrable d'ailleurs)...

C'est une pure merveille de gain de temps. Fini de chercher dans les menus, dans les cent icones qui encombre le double écran !

C'est open source, c'est pas laid, gratuit, et c'est "the" utility qu'il faut avoir.

L'adresse du site : http://www.launchy.net

Téléchargement sur SourceForge: http://sourceforge.net/project/showfiles.php?group_id=132975

Queques copies d'écran :

Launchy opening an .mp3 using the Default skin
Launchy opening Mozilla Firefox using the Black Glass skin
Launchy opening a .doc file using the Gantchy Blue Skin

 

Essayez-le, vous ne pourrez plus vous en passer !

Et... Stay Tuned !

Vous et le Framewok, résultat du sondage

Bien que la collecte des données continue, il est d'ores et déjà possible de dresser un premier bilan suite au sondage que je vous proposais en début de semaine "Vous et le Framework .NET".

En quatre questions qui n'ont pas pour ambition de cerner tous les cas possibles, on peut malgré tout voir des tendances, des envies, se dessiner. Je vous avais promis de vous livrer les résultats pour que votre participation à ce petit sondage soit remerciée par l'accès aux données, les voici (pour des raisons de mise en page ici j'ai préféré insérer une image que refaire les tableaux avec une CSS compatible avec le thème du blog) :

 

Constatations

je ne vais pas me livrer à de grandes analyses, vous savez lire les chiffres comme moi. On peut en revanche relever certaines choses intéressantes :

  • Le framework 3.5 semble largement adopté en production (58%)
  • Le framework 1.x n'a visiblement servi qu'aux tests et aux périodes d'apprentissage, voire a été "sauté" par une majorité d'utilisateurs puisque vous êtes 0% à déclarer l'utiliser en production ! Cela peut aussi signifier que les mises à jour du framework en production sont bien plus aisées que le "DLL Hell" de Win32 et que vous n'hésitez pas à faire évoluer les machines en production au rythme des grands changements du Framework. En tout cas, pas de 1.x en production, c'est une info peu surprenante mais maintenant on le sait :-)
  • Le Compact Framework est utilisé en production par 16% d'entre vous. Je suis surpris par ce résultat car je n'ai encore croisé aucun projet de ce type chez aucun de mes clients. Je ne sais pas tout et ne vois pas tout, c'est une évidence dont, rassurez-vous j'ai parfaitement conscience de longue date, mais une technologie .NET utilisée par presque 1/5 des développeurs que je n'aurai jamais vue nulle part en production ça me bluffe. En même temps je trouve ça particulièrement encourageant, comme vous je mise beaucoup sur l'avènement des technos mobiles. Vous êtes d'ailleurs 26% à déclarer que vous allez utiliser le Compact Framework dans les 12 mois à venir. J'aurai ainsi plus de chance de voir de telles réalisations en clientèle ! :-) Tout cela se réalisera-t-il oui bien s'agit-il d'un désir ? C'est toujours la délicate question de l'interprétation de ce type de question dans un sondage. Je me garderais de jouer aux experts et de proposer une réponse. Nous verrons d'ici un an !
  • Le Roi LINQ ! On peut l'appeler comme ça à la vue de vos réponses. 53% d'adoption pour LINQ to Objects c'est un score qui démontre la rapidité de pénétration de cette technologie et qui donne raison à tout le bien que j'en dis depuis le début ! Vous êtes même 84% à déclarer que vous utiliserez LINQ to Objects en production sous 6 mois. Génial. C'est vrai qu'une fois qu'on y a goûté on peut difficilement s'en passer. Si j'ai pu modestement y être pour un tout petit quelque chose dans l'intérêt que vous portez à cette technologie, j'en suis très content.
  • On remarque que LINQ to XML connaît le même succès, même s'il reste moins utilisé (47%) et que les prévisions d'utilisation sont moins spectaculaires (58%). Il reste donc des efforts d'information à fournir ! XML étant partout nous devrions avoir presque 100% d'utilisation de LINQ to XML qui simplifie grandement toutes les opérations sur ces sources de données. Cela confirme la place que je consacre à LINQ to XML dans mon prochain ouvrage (plus de news à ce sujet d'ici quelques semaines).
  • LINQ to SQL connaît un succès plutôt étonnant pour un OR/M (37% en production !) et vous êtes mêmes 47% à déclarer que vous utiliserez cette techno dans les prochains mois. Il va falloir vous calmer un peu sur LINQ to SQL. En effet, il fait un peu doublon avec LINQ to Entities tout en étant bien plus limité. De ce que je sais, Microsoft a décidé d'arrêter les frais sur LINQ to SQL au profit de LINQ to Entities. LINQ to SQL continuera d'exister mais n'espérez pas trop qu'il se charge de grosses nouveautés pour le faire ressembler à LINQ to Entities... Migrer dès maintenant vers l'Entity Framework dès maintenant et ne débutez plus de nouveaux projets en LINQ to SQL, c'est mon conseil du jour...
  • LINQ to Datasets est le parent pauvre du sondage : 0% en production ! Le pauvre...  Il y a forcément une raison derrière cet état de fait que le sondage ne peut pas percer. Le Dataset est-il de moins en moins utilisé ? Les techniques d'accès aux objets via LINQ et les collections d'objets ont-elles balayé les anciennes coutumes plus proche du SQL et des représentations en tables ? Vous êtes malgré tout 53% à déclarer que vous utiliserez cette techno dans les 6 mois. Renversement étonnant. Les commentaires de ce billet sont ouverts, n'hésitez pas à vous exprimer !
  • LINQ to Entities fait mouche, 11% en production, déjà un joli score pour une techno très récente et 68% de déclaration d'utilisation sous 6 mois. On voit à quel point l'objectivation des données via l'Entity Framework répond à une réelle attente. Continuez, LINQ to Entities c'est l'avenir, de façon bien plus pragmatique que d'espérer l'avènement des bases de données objet qui n'arrivera probablement jamais maintenant (en dehors de quelques succès d'estimes comme DB4O ou O2 dont l'utilisation en production est marginale).
  • Le Workflow (WF) est utilisé par 5% d'entre vous et 16% prévoient de s'en servir. C'est vraiment un beau score pour une techno très peu mise en avant, sur laquelle on trouve peu de ressources et d'exemples. Mais que ceux qui se lancent dans cette voie se rassurent, WF s'imposera avec le temps. Il faut juste laisser un peu de temps aux développeurs pour digérer toutes les nouveautés de .NET qui sont toutes aussi essentielles les unes que les autres. Hélas les journées ne comptent que 24h !
  • WPF est adopté par 21% d'entre vous. C'est encore un peu faible, mais vous êtes 53% à déclarer vouloir l'utiliser en production dans les 6 mois. Adios WinForms ? Très certainement, à termes. Reste à maîtriser WPF, Blend, Design et à trouver un copain ou une copine infographiste. Car si faire du WPF c'est juste poser des composants sur une fiche et utiliser des thèmes "tout fait", c'est en utiliser 10% des possibilités, autant rester en WinForms... Je ne doute pas un instant que vous l'avez compris et que vous avez déjà passé des annonces pour recruter un graphiste ! :-)
  • Xbap, 5% en production, 16% d'intention. Que dire de plus. Microsoft même ne pousse pas / plus cette techno pourtant séduisante à plus d'un titre. Mais cela se comprend. Xbap ce sont les possibilités graphiques de WPF avec les limitations du Web et l'obligation d'une cible Internet Explorer. A ce jeu là Silverlight tire son épingle du jeu. Si les limites du Web sont les mêmes, et même si son support de WPF et du framework est plus limité que Xbap, Silverlight offre la portabilité Mac/Linux et ne se limite pas à IE. Xbap restera vraisemblablement une techno de niche, répondant à des besoins très ponctuels. Ailleurs Silverlight sera préféré.
  • Avec 32% en production Silverlight confirme ce que je disais. Il faut dire que la sortie de la V2 et de tous ces avantages secoue le cocotier ! 53% d'entre vous déclare qu'ils vont utiliser Silverlight dans les 6 mois. C'est une adoption massive qui semble donc s'annoncer. Je pense d'ailleurs que c'est par Silverlight que WPF s'imposera et séduira. C'est ce qui semble se produire. Les retombées WPF desktop auront lieu plus tard, lorsque Windows 7 aura pris la place que Vista aurait du occuper sur le marché.
  • WCF est bien installé (53%) et stable (53%) ! La communication prend une place importante dans les développements, ce qui est logique et dans l'air du temps.
  • Reste les "autres" technologies. J'avais laissé ouvert cette possibilité car je sais bien que certaines personnes n'aiment pas se sentir coincer par un questionnaire fermé... Parmi celles en production (les technos par les personnes!) on notera, par force WinForms, ASP.NET qui ne faisait pas partie de mon sondage, la techno est moins récente que celles que j'avais choisi de sonder, ASP.NET Ajax et de façon amusante "aucune et N/A". Dans les intentions sous 6 mois on voir revenir ASP.NET Ajax, ce qui semble normal et une personne qui indique ASP.NET MVC (Sylvain tu es démarqué !).

Conclusion

Il n'y a rien à conclure, je ne vous jouerai pas le jeu des sondeurs avant les élections qui se plantent à chaque fois. A vous de conclure ! J'ai juste profité de quelques constats pour discuter un peu. Vos commentaires sont les bienvenus !

C# - Les optimisations du compilateur dans le cas du tail-calling

Les optimisations du compilateurs C# ne sont pas un sujet de discussion très courant, en tout cas on voit très nettement que le fait d'avoir quitté l'environnement Win32 pour l'environnement managé de .NET a fait changer certaines obsessions des codeurs... Ce n'est pas pour autant que le sujet a moins d'intérêt ! Nous allons voir cela au travers d'une optimisation particulière appelée "tail-calling" (appel de queue, mais je n'ai pas trouvé de traduction française, si quelqu'un la connaît, qu'il laisse un commentaire au billet).

Principe

On appelle "tail-calling" un mécanisme d'optimisation du compilateur qui permet d'économiser les instructions exécutées en même temps que des accès à la pile. Les circonstances dans lesquelles le compilateur peut utiliser cette optimisation sont celles où une méthode se termine par l'appel d'une autre, d'où le nom de tail-calling (appel de queue).

Prenons l'exemple suivant :

static public void Main()
{
    Go();
}
 
static public void Go()
{
    Première();
    Seconde();
    Troisième();
}
 
static public void Troisième()
{
}

Dans cet exemple le compilateur peut transformer l'appel de Troisième() en un appel de queue (tail-calling). Pour mieux comprendre regardons l'état de la pile au moment de l'exécution de Seconde()  : Seconde()-Go()-Main()

Quand Troisième() est exécutée il devient possible, au lieu d'allouer un nouvel emplacement sur la pile pour cette méthode, de simplement remplacer l'entrée de Go() par Troisième(). La pile ressemble alors à Troisième()-Main().

Quand Troisième() se terminera elle passera l'exécution à Main() au lieu de transférer le trait à Seconde() qui immédiatement devra le transférer à Main().

C'est une optimisation assez simple qui, cumulée tout au long d'une application, et ajoutée aux autres optimisations, permet de rendre le code exécutable plus efficace.

Quand l'optimisation est-elle effectuée ?

La question est alors de savoir quand le compilateur décide d'appliquer l'optimisation de tail-calling. Mais dans un premier temps il faut se demander de quel compilateur nous parlons.... Il y existe en effet deux compilateurs dans .NET, le premier prend le code source pour le compiler en IL alors que le second, le JIT, utilisera ce code IL pour créer le code natif. La compilation en IL peut éventuellement placer certains indices qui permettront de mieux repérer les cas où le tail-calling est applicable mais c'est bien entendu dans le JIT que cette optimisation s'effectue.

Il existe de nombreuses règles permettant au JIT de décider s'il peut ou non effectuer l'optimisation. Voici un exemple de règles qui font qu'il n'est pas possible d'utiliser le tail-calling (par force cette liste peut varier d'une implémentation à l'autre du JIT) :

  • L'appelant ne retourne pas directement après l'appel;
  • Il y a une incompatibilité des arguments passés sur la pile entre l'appelant et l'appelé ce qui imposerait une modification des arguments pour appliquer le tail-calling;
  • L'appelant et l'appelé n'ont pas le même type de retour (données de type différents, void);
  • L'appel est est transformé en inline, l'inlining étant plus efficace que le tail-calling et ouvrant la voie à d'autres optimisations;
  • La sécurité interdit ponctuellement d'utiliser l'optimisation;
  • Le compilateur, le profiler, la configuration ont coupé les optimisations du JIT.

Pour voir la liste complète des règles, jetez un oeil à ce post.

Intérêt de connaitre cette optimisation ?

Normalement les optimisations du JIT ne sont pas un sujet intéressant au premier chef le développeur. D'abord parce qu'un environnement managé comme .NET fait qu'à la limite ce sont les optimisations du code IL qui regarde directement le développeur et beaucoup moins la compilation native qui peut varier d'une plateforme à l'autre pour une même application. Ensuite il n'est pas forcément judicieux de se reposer sur les optimisations du JIT puisque, justement, ce dernier peut être différent sans que l'application ne le sache.

Qui s'intéresse à l'optimisation du tail-calling alors ? Si vous écrivez un profiler c'est une information intéressante, mais on n'écrit pas un tel outil tous les jours... Mais l'information est intéressante lorsque vous déboguez une application car vous pouvez vous trouver face à une pile d'appel qui vous semble "bizarre" ou "défaillante" car il lui manque l'une des méthodes appelées !

Et c'est là que savoir qu'il ne faut pas chercher dans cette direction pour trouver le bug peut vous faire gagner beaucoup de temps... Savoir reconnaître l'optimisation de tail-calling évite ainsi de s'arracher les cheveux dans une session de debug un peu compliquée si on tombe en plus sur un pile d'appel optimisée. Un bon debug consiste à ne pas chercher là où ça ne sert à rien (ou à chercher là où c'est utile, mais c'est parfois plus difficile à déterminer !), alors rappelez-vous du tail-calling !

Et stay tuned !

nota: le présent billet est basé sur un post de l'excellent blog ASP.NET Debugging

20 Ko pour une mire bien pratique

Tous les environnements de développement sérieux permettent de connaître et de fixer la taille des objets, notamment des fenêtres. Mais dans certains cas il est important de tester l'aspect d'une application dans différentes résolutions écrans.

Il existe cent façons de faire, personnellement je me suis fait une petite mire qui va de 800x600 à 1680x1050 qu'il suffit de placer en image de fond du bureau. Ensuite il n'y a plus qu'à caler l'application en test sur les lignes pour avoir immédiatement, sans calcul et visuellement, le résultat escompté.

Tout bête. Mais comme ça peut rendre service je vous offre la mire (un png de 23Ko, ça n'encombrera pas les Tera de vos disques durs !) : MireResoEcranOD.png (22,97 kb)

Pour un petit aperçu (déformé, par force):

Contre la riposte graduée, secouez vos sénateurs (1 minute et 1 clic)

Si vous lisez ce billet régulièrement vous savez que j'aime de temps en temps gueuler un coup contre des choses qui me scandalisent. Aujourd'hui il s'agit de la riposte graduée qui se décide dans notre dos. Il ne faut pas laisser faire le gouvernement qui transforme notre démocratie en dictature : une peine appliquée sans jugement est un acte non plus de république bananière mais de simple dictature !

L'association ODEBI, vous la connaissez certainement, a organisé une pétition par email qui arrive directement chez les sénateurs. Il faut la signer, c'est un acte citoyen élémentaire.

L'adresse de la pétition est là : http://www.odebi.org/new2/?page_id=493

Le texte de la pétition pour que vous puissiez vous rendre compte du sérieux de la démarche avant de cliquer sur le lien plus haut pour vous engager dans cette lutte:

Les sénateurs français doivent réaliser que la riposte graduée est un mécanisme répressif totalement contraire aux droits les plus élémentaires des citoyens:

- Chaque citoyen a droit à un procès équitable avant toute sanction: c’est le juge indépendant et impartial, et lui seul, qui est le gardien des libertés.

- La liberté d’expression et d’information est un droit fondamental: il est scandaleux que la commission des affaires culturelles du sénat tente de le nier en affirmant qu’aucun texte communautaire n’affirme que l’accès à internet serait un droit fondamental. L’accès à internet permet d’exercer cette liberté d’expression et d’information: supprimer cet accès est donc à l’évidence une atteinte majeure à cette liberté. Cette sanction est totalement disproportionnée.

- La commission des affaires culturelles précise que la suspension ne concerne que l’accès à domicile, c’est à dire l’accès familial: il s’agit donc bien de punir les familles, et elles seules. Aucune démocratie ne peut accepter d’infliger des punitions collectives, ce qui a été rappelé par Michel Rocard le 22 avril 2008: « Pour moi, la coupure éventuelle de l'Internet est une punition collective, principe interdit par tous nos systèmes de droit. La lettre des textes est claire et il n’y a aucun problème sophistiqué de compréhension là derrière. »

Les sénateurs français doivent donc garantir:

- que seul le juge peut décider d’une sanction.

- que la suspension d’accès d’une famille, punition collective, soit clairement prohibée.

C'est simple, court, je pense que vous pensez la même chose, alors signez la pétition et faite la circuler autour de vous !

 

Vous et le framework .NET

Dans la jungle des technologies .NET il est intéressant de savoir ce que vous utilisez déjà en production et ce que vous prévoyez d'utiliser dans ce contexte. Je parle bien de production, pas des essais que nous faisons tous et qui remplissent nos machines, non, uniquement ce qui est installé chez des clients (ou utilisateurs) ou en cours de développement.

Comme je ne vais pas vous demander de laisser un message à ce billet et puis faire le tri après, pour faire plus simple j'ai mis en place un petit sondage. D'ici quelques temps je "relèverai les compteurs" et je les publierai ici. Répondre à ce sondage est ainsi un moyen simple pour que nous sachions les uns les autres ce qui est utilisé (ou en prévision d'utilisation). 

Merci d'avance de prendre une minute pour réponse au sondage qui se trouve ici :

Cliquez ici pour lancer le sondage.

Stay Tuned pour les résultats (et pour bien d'autres news entre temps...) !