Commentaires

  1. Avatar de landry161
    • |
    • permalink
    L'une des raisons pour lesquelles j'ai commencé à publier des articles sur Developpez.com, c'était dans l'optique de partager ce que je savais ou du moins le peu que j'avais appri grâce au site et aussi grâce à d'autres développeurs qui étaient nettement plus expérimentés que moi.

    Je me souviens du jour où j'en ai parlé à une connaissance. La question qu'elle m'a posée c'était "est ce qu'ils vont te payer? " Bien sûr que non mais le plus important pour moi était de partager. Car je reste persuadé que la meilleure manière d'apprendre est de partager.

    Aujourd'hui je comprends que publier un article demande beaucoup d'efforts. Chose que je n'aurais jamais pu savoir si je n'avais jamais tenté le coup. Un article si simple soit-il est toujours utile à plus d'un. A titre d'exemple, il y a quelques années de cela j'avais rédigé un article sur PostgreSQL et le langage C#. Une personne m'avait contacté en privé pour me dire qu'elle s' en était servie dans le cadre d'un projet. L'article en lui-même n'était pas quelque d'extraordinaire mais il avait été utile à quelqu'un.
    J'étais tout heureux

    Merci au site pour tout ce que vous nous permettez d'apprendre chaque jour (tutoriels de débutants,intermédiaires ou confirmés).
  2. Avatar de Bruno Orsier
    • |
    • permalink
    Même arguments pour moi il y a plus de 10 ans, et je suis bien content que mes articles/tutoriels TDD soient toujours là sans aucun travail de ma part depuis cette période !

    Bruno
  3. Avatar de ryankarl65
    • |
    • permalink
    Wouahhh !!!

    Quel serait ? ou quel pourrait être l'utilité d'une telle pratique ?
  4. Avatar de juju26
    • |
    • permalink
    Citation 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.
  5. Avatar de Aurelien.Regat-Barrel
    • |
    • permalink
    Citation 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.
    Mis à jour 25/10/2018 à 17h12 par Aurelien.Regat-Barrel
  6. Avatar de François DORIN
    • |
    • permalink
    Citation 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é.
  7. Avatar de no2303
    • |
    • permalink
    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 ?
  8. Avatar de ekinoks60
    • |
    • permalink
    Hello,

    Merci beaucoup pour les explications !
  9. Avatar de François DORIN
    • |
    • permalink
    Citation 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.

    Citation 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.
  10. Avatar de Aurelien.Regat-Barrel
    • |
    • permalink
    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 ?
  11. Avatar de maitredede
    • |
    • permalink
    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 ?
  12. Avatar de François DORIN
    • |
    • permalink
    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.
  13. Avatar de tomlev
    • |
    • permalink
    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.
  14. Avatar de François DORIN
    • |
    • permalink
    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.
  15. Avatar de lafarge
    • |
    • permalink
    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 !
  16. Avatar de François DORIN
    • |
    • permalink
    Sur quel(s) aspect(s) ?
  17. Avatar de lafarge
    • |
    • permalink
    Quelques ressemblance avec les Objets Com/DCom ! Non ??
  18. Avatar de François DORIN
    • |
    • permalink
    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.
  19. Avatar de blbird
    • |
    • permalink
    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?
  20. Avatar de François DORIN
    • |
    • permalink
    J'ai rajouté un petit morceau de code. Est-ce plus parlant ainsi ?
Page 1 sur 6 12345 ... DernièreDernière