Commentaires

Wouahhh !!!

Quel serait ? ou quel pourrait être l'utilité d'une telle pratique ?

Envoyé par badoquealex

..Pour moi, la principale faiblesse est l'impossibilité de déployer une application hors du Windows Store,...

Pour moi c'est la raison n°1.. et je ne pense pas être le seul dans ce cas.
Être tributaire d'un store non merci. D’ailleurs nous n'avons jamais porté nos app sur Android/ios juste pour ces raison. Donc utilisation des Webapp.

Envoyé par François DORIN

Le cas reste très rare, mais une classe managée qui serait un simple wrapper à du code natif pourrait se retrouver dans une telle situation, avec des surprises à la clé.

Cette partie là m'intéresse, et j'ai un peu de mal tout de même à voir quel problème concret pourrait apparaître dans la mesure où cela ne concerne PAS les méthodes qui référencent une variable d'instance. Car l'exemple donné revient à écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Program p = new Program();
Program.SayHello();
Console.ReadLine();

et dans ce cas on comprend très bien que l'appel de SayHello() n'est pas lié à l'instance p. Jusque là tout va bien.

Ce qui est plus surprenant en revanche c'est l'appel du destructeur avant que l'appel du constructeur soit finalisé. Là aussi c'est à priori lié au fait que le destructeur ne fait rien sur l'instance elle même, donc bien que surprenant de prime abord cela fait sens et ne pose pas problème. Car je suppose que si le dtor référençait une variable initialisée par le ctor afin de la libérer, ce cas là ne se produirait pas. Et donc tout irait bien.

Pour aller dans ton sens, le cas hypothétique que je peux imaginer est celui où ctor et dtor ne font qu'appeler des fonctions statiques d'une lib afin de faire un init / shutdown. Donc là il pourrait y avoir potentiellement une inversion de l'ordre d'appel. Il faudrait (je pense) utiliser un ctor statiques dans ce cas. Y'a pas de dtor statique en C# je crois, mais on peut le simuler il me semble.

Envoyé par no2303

Le "comment" est effectivement intéressant, mais "pourquoi" faire ça ?

Le but n'est pas de pouvoir le faire, car ce n'est pas un choix qui est du ressort du développeur ou du concepteur.

Il s'agit de comprendre ce qui se passe quand ça ne se passe pas comme attendu. Le cas reste très rare, mais une classe managée qui serait un simple wrapper à du code natif pourrait se retrouver dans une telle situation, avec des surprises à la clé.

Le "comment" est effectivement intéressant, mais "pourquoi" faire ça ? Ça manque un peu à l'article. Est-ce que c'est juste parce que c'est possible et qu'il faut le mentionner "for the sake of completeness" ?

Je peux aussi couper mon steak avec une scie à métaux, mais dans quel cas est-ce préconisé, et qu'est-ce que ça va m'apporter ?

Hello,

Merci beaucoup pour les explications !

Envoyé par maitredede

Et aussi, pour l'inlining, est-ce que l'utilisation de MethodImplAttribute avec
[MethodImplAttribute(MethodImplOptions.NoInlining)]
serait une possibilité si on tombe dans un cas similaire ?

Sans doute oui. A vérifier cependant, car il me semble que cet attribut n'est qu'une indication, et que le compilateur n'est pas obligé de suivre la directive.

Envoyé par Aurelien.Regat-Barrel

Au delà du simple inlining, je suppose que c'est aussi (voire surtout) une conséquence du fait que la méthode concernée est une méthode static déguisée ? Est-ce que cela marcherait de la même façon si au lieu d'afficher une string constante, elle affichait la valeur d'une variable membre de la classe ?

Effectivement, si la méthode était une "vraie" méthode, avec une variable membre, le problème ne se poserait pas, et le ramasse-miettes ne pourrait pas collecter la variable.

Au delà du simple inlining, je suppose que c'est aussi (voire surtout) une conséquence du fait que la méthode concernée est une méthode static déguisée ? Est-ce que cela marcherait de la même façon si au lieu d'afficher une string constante, elle affichait la valeur d'une variable membre de la classe ?

Bonjour,

Intéressant, détruire pendant qu'on construit

Pour autant que je me rappelle, quand j'utilisais mono embarqué, l'instantiation de l'objet et l'appel au constructeur étaient deux opérations distinctes, le constructeur étant une "méthode comme une autre" pour l'appel. Du coup, ça ne me parait pas si surprenant que le constructeur et le destructeur puissent être appelées en même temps (même si c'est assez tordu...)

Du coup, quels seraient les effets de bord en terme d'allocation mémoire d'objets détruits pendant leur construction ?

Et aussi, pour l'inlining, est-ce que l'utilisation de MethodImplAttribute avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

[MethodImplAttribute(MethodImplOptions.NoInlining)]

serait une possibilité si on tombe dans un cas similaire ?

Je le présente comme un problème car cela "casse" le polymorphisme classique. Mais on peut effectivement, avec ce que tu viens justement de souligner, créer un polymorphisme directement au niveau des interfaces.

Maintenant, c'est un soucis car il n'est pas possible de préciser le comportement souhaité. Par exemple, si on surcharge une méthode virtuelle, on peut utiliser soit new, soit override pour préciser si l'on souhaite réimplémenter une méthode, ou si on souhaite "masquer" la méthode de la classe parente. Chose impossible ici malheureusement.

Intéressant! Mais tu décris ce comportement comme un problème, alors que finalement il me semble assez logique, et peut parfois être utile. Par exemple si tu dois hériter d'une classe C qui implémente une interface I, et tu voudrais overrider la méthode M mais elle n'est pas virtuelle : tu peux quand même t'en sortir en implémentant l'interface explicitement.

Je crois que je ne comprenais pas votre question car je n'arrivais pas à faire le lien entre "interface explicite" et composants COM. Mais en fait, votre question, c'est le lien entre "interface" et composants COM.

Le principe est effectivement similaire. Les interfaces sont quelques choses de courant et que l'on retrouve en principalement en Programmation Orienté Objet (mais pas que). Une classe doit impérativement et scrupuleusement respecter les interfaces dont elle dérive.

Maintenant, la grosse différence que je vois, c'est qu'en POO, les interfaces sont généralement définies avant les classes. Les classes implémentent ensuite les interfaces pour respecter les contrats.

Dans le cas des composants COM, l'implémentation du composant existe généralement avant, et on définie une interface afin de proposer une API publique d'accès à ce composant, pour pouvoir le réutiliser ensuite.

Enfin, les deux sont très différents dans leur objectif. Les interfaces en POO ont pour rôle de créer de l'abstraction (en définissant un contrat), tandis que les composants COM ont pour rôle de permettre de réutiliser des composants, quelle que soit la technologie utilisée derrière.

Sur l'aspect contrat Interface - Implémentation. Ce dernier devant suivre scrupuleusement ce qui était défini dans l'interface. Enfin me semble t'il !

Sur quel(s) aspect(s) ?

Quelques ressemblance avec les Objets Com/DCom ! Non ??

Non, on ne peut pas le considérer comme cela, puisque la "surcharge" n'est pas appelable directement depuis la classe. On pourrait plutôt le voir comme une redéfinition.

En fait c'est une surcharge de classe, possible car la méthode réelle de l'interface est déclarée comme étant explicitement propre à l'interface?

J'ai rajouté un petit morceau de code. Est-ce plus parlant ainsi ?

Grand merci pour cet article très clair et très agréable à lire.
Cependant je bute sur l’explication finale (à partir de "Qu'est-ce que cela signifie ?[...]").
Pourriez-vous détailler un peu plus le fonctionnement ? Je suis frustré de coincer sur la partie qui explicite le tout

On retrouve comme autre cas TcpClient. En version 4.5, Dispose est non accessible. Dans la version 4.7 elle est publique et une méthode Dispose(bool) a été ajoutée.