x = x +1 contre x + = 1

Question

J'ai l'impression que ces deux commandes aboutissent à la même fin, à savoir incrémenter X de 1 mais que cette dernière est probablement plus efficace.

Si ce n'est pas correct, veuillez expliquer le diff.

Si elle est correcte, pourquoi cette dernière devrait-elle être plus efficace? Ne devraient-ils pas tous les deux compiler vers le même IL?

Merci.

Answer 1

À partir de la bibliothèque MSDN pour +=:

À l'aide de cet opérateur est presque la même que la spécification result = result + expression, sauf que le résultat n'est évaluée qu'une fois.

Donc ils ne sont pas identiques, et c'est pourquoi x += 1 sera plus efficace.

Mise à jour: je viens de remarquer que ma Bibliothèque MSDN lien a été à la JScript page au lieu de la VB page, qui ne contiennent pas la même citation.

Donc sur d'autres recherches et d'essais, la réponse ne s'applique pas à VB.NET. J'ai eu tort. Voici un exemple d'une application de console:

Module Module1

Sub Main()
    Dim x = 0
    Console.WriteLine(PlusEqual1(x))
    Console.WriteLine(Add1(x))
    Console.WriteLine(PlusEqual2(x))
    Console.WriteLine(Add2(x))
    Console.ReadLine()
End Sub

Public Function PlusEqual1(ByVal x As Integer) As Integer
    x += 1
    Return x
End Function

Public Function Add1(ByVal x As Integer) As Integer
    x = x + 1
    Return x
End Function

Public Function PlusEqual2(ByVal x As Integer) As Integer
    x += 2
    Return x
End Function

Public Function Add2(ByVal x As Integer) As Integer
    x = x + 2
    Return x
End Function

End Module

IL pour les deux PlusEqual1 et Add1 sont en effet identiques:

.method public static int32 Add1(int32 x) cil managed
{
.maxstack 2
.locals init (
    [0] int32 Add1)
L_0000: nop 
L_0001: ldarg.0 
L_0002: ldc.i4.1 
L_0003: add.ovf 
L_0004: starg.s x
L_0006: ldarg.0 
L_0007: stloc.0 
L_0008: br.s L_000a
L_000a: ldloc.0 
L_000b: ret 
}

Le IL pour PlusEqual2 et Add2 sont quasiment identiques ainsi:

.method public static int32 Add2(int32 x) cil managed
{ 
.maxstack 2
.locals init (
    [0] int32 Add2)
L_0000: nop 
L_0001: ldarg.0 
L_0002: ldc.i4.2 
L_0003: add.ovf 
L_0004: starg.s x
L_0006: ldarg.0 
L_0007: stloc.0 
L_0008: br.s L_000a
L_000a: ldloc.0 
L_000b: ret 
}

Answer 2

J'ai écrit une application console simple:

 static void Main(string[] args)
{
    int i = 0;
    i += 1;
    i = i + 1;
    Console.WriteLine(i);
}
 

Je l'ai démonté à l'aide de Reflector et voici ce que j'ai obtenu:

 private static void Main(string[] args)
{
    int i = 0;
    i++;
    i++;
    Console.WriteLine(i);
}
 

Ce sont les mêmes.

Answer 3

ils compilent la même chose, le second est juste plus facile à taper.

Answer 4

IMPORTANT:

Les réponses en précisant l'évaluation sont certainement correctes en termes de ce qu'un += le font, en général les langues. Mais dans VB.NET, je suppose X spécifié dans l'OP est une variable ou d'une propriété.

---

Ils vont probablement compiler à la même IL.

Mise à JOUR (à l'adresse de probablement la polémique):

VB.NET est une spécification d'un langage de programmation. Un compilateur qui est conforme à ce qui est défini dans la spécification peut être un VB.NET la mise en œuvre. Si vous modifiez le code source de MS VB.NET compilateur de générer de merde de code pour X += 1 des cas, vous aurez toujours se conformer à VB.NET spec (parce qu'il n'a rien dit sur la façon dont il va fonctionner. Il dit seulement à l'effet sera exactement le même, ce qui rend logique pour générer le même code, en effet).

Alors que le compilateur est très très probable (et j'ai l'impression qu'il fait vraiment) générer le même code pour les deux, mais c'est assez complexe d'un morceau de logiciel. Heck, vous pouvez même pas de garantie qu'un compilateur génère exactement le même code lorsque le même code est compilé à deux fois!

Ce que vous pouvez vous sentir sécurisé à 100% pour le dire (sauf si vous connaissez le code source du compilateur intimement) est-ce un bon compilateur doit générer le même code, en terme de performance, ce qui pourrait ou ne pourrait pas être l' exacte même code.