J'ai écrit un programme qui permet à deux classes de "lutte". Quelle que soit la raison de C# gagne toujours. Quel est le problème avec VB.NET?

Question

J'ai écrit un programme qui permet à deux classes de "lutte". Quelle que soit la raison de C# gagne toujours. Quel est le problème avec VB.NET ?

   static void Main(string[] args)
    {
        Player a = new A();
        Player b = new B();

        if (a.Power > b.Power)
            Console.WriteLine("C# won");
        else if (a.Power < b.Power)
            Console.WriteLine("VB won");
        else
            Console.WriteLine("Tie");
    }

Voici les joueurs: Le joueur A en C#:

public class A : Player
{
    private int desiredPower = 100;

    public override int GetPower
    {
        get { return desiredPower; }
    }
}

Le joueur B en VB.NET:

Public Class B
   Inherits Player

   Dim desiredPower As Integer = 100

   Public Overrides ReadOnly Property GetPower() As Integer
       Get
          Return desiredPower
       End Get
   End Property
 End Class

Et ici, c'est une classe de base.

public abstract class Player
{
    public int Power { get; private set; }

    public abstract int GetPower { get; }

    protected Player()
    {
        Power = GetPower;
    }
}

Answer 1

Le problème ici est que VB est d'appeler le constructeur de base avant de définir sa valeur de champ. De sorte que la base de classe de Joueur magasins de zéro.

.method public specialname rtspecialname 
        instance void  .ctor() cil managed
{
  // Code size       15 (0xf)
  .maxstack  8
  IL_0000:  ldarg.0
  IL_0001:  call       instance void [base]Player::.ctor()
  IL_0006:  ldarg.0
  IL_0007:  ldc.i4.s   100
  IL_0009:  stfld      int32 B::desiredPower
  IL_000e:  ret
} // end of method B::.ctor

Answer 2

La promotion de mes commentaires pour la réponse:

Moi:

Essayez d'écrire chaque "puissance" de la console

Farceur:

C#: 100 VB.NET: 0

Moi:

Comme je le soupçonnais. Ressemble VB.Net est d'appeler le constructeur de Base avant hérité du constructeur, et donc VB est desiredPower variable est toujours de 0, alors que C# dans le sens inverse (rappelez-vous, littérale de l'initialisation se passe à la fin du constructeur).

Mise à jour:
Je voulais trouver de la documentation sur le comportement. À partir du lien:

Le constructeur de la classe dérivée implicitement appelle le constructeur de la classe de base

et

Classe de Base des objets sont toujours construits avant toute dérivant de la classe. Ainsi, le constructeur de la classe de base est exécuté avant que le constructeur de la classe dérivée.

Ceux qui sont sur la même page et semble être mutuellement exclusives, mais je prends ça pour dire que le constructeur de la classe dérivée est appelée en premier, mais il est supposé que elle-même invoquer le constructeur de base avant de faire tout autre travail. Par conséquent, il n'est pas le constructeur de l'ordre qui importe, mais la manière dont les littéraux sont initialisés.

J'ai aussi trouvé cette référence, qui dit clairement que l'ordre est dérivé des champs d'instance, puis constructeur de base, puis dérivé du constructeur.

Answer 3

Au moment où le constructeur sur B est terminée, les deux joueurs ont une valeur théorique de 100 de leurs membres privés.

Cependant, en raison de la supériorité de la partie interne de C#, de la CLI considère généralement que les entiers et les autres valeurs primitives valeurs compilées à partir de cette langue à être plus élevé, et ceux de VB.NET à être plus faible, même lorsqu'ils contiennent les mêmes bits.

Answer 4

Cela se produit parce que le C# d'abord initialiser les champs de la classe, et que l'appel de la base de constructeurs. VB plutôt fait le contraire, donc dans le VB vous attribuer de la valeur à votre Alimentation, domaine privé n'est pas encore initialisée et sa valeur est de 0.