C#, seltsame Optimierung

Question

Ich versuche, meinen kompilierten C# -Code zu lesen.

dies ist mein Code:

using(OleDbCommand insertCommand = new OleDbCommand("...", connection)) 
{ 
    // do super stuff 
} 

Aber!

Wir alle wissen, dass eine Verwendung zu dieser übersetzt wird:

{ 
    OleDbCommand insertCommand = new OleDbCommand("...", connection) 
    try 
    { 
     //do super stuff 
    } 
    finally 
    { 
     if(insertCommand != null) 
      ((IDisposable)insertCommand).Dispose(); 
    } 
} 

(seit OleDbCommand ist ein Referenz-Typ).

Aber wenn ich meine Montage decompile (kompiliert mit .NET 2.0) bekomme ich diese in ReSharper:

try 
{ 
    insertCommand = new OleDbCommand("", connection); 
Label_0017: 
    try 
    { 
     //do super stuff 
    } 
    finally 
    { 
    Label_0111: 
     if ((insertCommand == null) != null) 
     { 
      goto Label_0122; 
     } 
     insertCommand.Dispose(); 
    Label_0122:; 
    } 

ich über diese Linie rede: if ((insertCommand == null) != null).

Nehmen wir an, insertCommand ist null. Dann gibt der erste Teil wahr zurück. (true != null) gibt true zurück. Also dann wird die Entsorgung noch übersprungen? Seltsam, sehr komisch.

Wenn ich das in Visual Studio einfügen, ReSharper schon warnt mich: Ausdruck immer wahr ist ...

Dank!

-Kristof

Answer 1

Der Decompiler hat einen Fehler. Diese Linie

if ((insertCommand == null) != null) 

haben sollte

if ((insertCommand == null) != false) 

die, wenn auch unnötig ausführlich, zu

dekompilierten mindestens richtigen Code ist.

Der Decompiler wahrscheinlich tut dies unnötig ausführliche Version, da der C# Compiler oft

if (x) 
    Y(); 
Z(); 

, als ob Sie

if (!x) 
    goto L; 
Y(); 
L: Z(); 

geschrieben hatte auszusenden wählt Da die für beide Programme generierten Code gleich ist , der Decompiler weiß nicht immer, welcher der sinnvollere Code ist.

Der Grund für das Unerwartete "!= false "ist, weil, wenn wir IL generieren, die testet, ob etwas wahr ist, der schnellste und kompakteste Code, den wir erzeugen können, ist zu testen, ob es nicht falsch ist. Falsch wird in IL als Null dargestellt, und es gibt eine billige Anweisung für" ist Dieses Ding Null?

Answer 2

, wenn Sie Code dekompilieren, Sie sind nicht garantiert wieder den ursprünglichen Code zu erhalten. Wenn .net-Code in IL kompiliert wird, wird es optimiert. Manchmal werden Sie etwas verrückt sehen, wenn eine Anwendung die IL zurück in C# übersetzt. Dies bedeutet nicht, dass der Code nicht funktioniert, es ist nur, wie die Anwendung (in diesem Fall nachgeschärft) die IL übersetzt.

Wenn Sie sich Sorgen machen, würde ich direkt in die IL schauen, um zu sehen, in was es kompiliert wurde.

Side Hinweis: dekompilierte IL in C# oder VB.net ist nicht garantiert, zu kompilieren. :)

Ein weiteres Produkt ist zu versuchen, Reflector