Casting und Verwendung des Schlüsselworts 'as' in der CLR

Die Antwort unter die Linie geschrieben wurde, im Jahr 2008.

C# 7 eingeführt, pattern-matching, die weitgehend ersetzt die as Betreiber, da kann man jetzt schreiben:

if (randomObject is TargetType tt)
{
    //Use tt here
}

Beachten Sie, dass tt ist noch im Rahmen, nachdem diese, aber nicht definitiv zugewiesen. (Es ist definitiv zugeordnet, die innerhalb der if Körper.) Das ist etwas ärgerlich, in einigen Fällen, so wenn Sie wirklich über die Einführung der kleinsten Anzahl von Variablen möglich, in jedem Bereich, die Sie vielleicht noch nutzen möchten is gefolgt von einer Besetzung.

Ich glaube nicht, dass die Antworten so weit (zum Zeitpunkt der Beginn dieser Antwort!) haben wirklich erklärt wird wo es sich lohnt mit denen.

• Nicht tun:

  //Bad code - checks type twice for no reason
  if (randomObject is TargetType)
  {
      TargetType foo = (TargetType) randomObject;
      //Do something with foo
  }

  Dies ist nicht nur die überprüfung zweimal, aber es kann die überprüfung verschiedener Dinge, wenn randomObject ist ein Feld, anstatt eine lokale variable. Es ist möglich für die "wenn" zu übergeben, aber dann ist der cast fehl, wenn ein anderer thread, ändert sich der Wert von randomObject zwischen den beiden.

• Wenn randomObject wirklich sollte eine Instanz von TargetType ist, D. H. wenn es ist nicht, bedeutet, dass es ein bug ist, dann ist der Guss die richtige Lösung. Das wirft eine Ausnahme sofort, was bedeutet, dass keine weitere Arbeit erfolgt unter falschen Annahmen beruhen, und die Ausnahme korrekt zeigt die Art der Fehler.

  //This will throw an exception if randomObject is non-null and
  //refers to an object of an incompatible type. The cast is
  //the best code if that's the behaviour you want.
  TargetType convertedRandomObject = (TargetType) randomObject;

• Wenn randomObject könnte eine Instanz von TargetType und TargetType ist ein Referenz-Typ, dann verwenden Sie code wie diesen:

  TargetType convertedRandomObject = randomObject as TargetType;
  if (convertedRandomObject != null)
  {
      //Do stuff with convertedRandomObject
  }

• Wenn randomObject könnte eine Instanz von TargetType und TargetType ist ein Werttyp, dann können wir Sie nicht verwenden as mit TargetType selbst, aber wir können eine nullable-Typ:

  TargetType? convertedRandomObject = randomObject as TargetType?;
  if (convertedRandomObject != null)
  {
      //Do stuff with convertedRandomObject.Value
  }

  (Hinweis: derzeit ist dies tatsächlich langsamer als + cast. Ich denke, es ist mehr elegant und konsistent, aber es wir gehen.)

• Wenn Sie wirklich nicht brauchen, wird der umgewandelte Wert, aber Sie müssen nur wissen, ob es ist eine Instanz von TargetType, dann die is - operator ist dein Freund. In diesem Fall ist es egal, ob TargetType ist ein Verweistyp oder ein Werttyp ist.

• Möglicherweise gibt es andere Fälle, in denen Generika wo is nützlich ist (vielleicht, weil Sie nicht wissen, ob T ein Referenztyp oder nicht, so können Sie nicht benutzen) aber Sie sind relativ vage.

• Bin ich fast sicher verwendet werden is für den Wert geben Sie den Fall nun vor, nicht mit Gedanke, mit einem nullable-Typ und as zusammen 🙂

EDIT: Beachten Sie, dass keines der oben genannten Gespräche über Leistung, andere als die Wert-Typ Fall, wo habe ich festgestellt, dass unboxing, um eine null-value Typ ist wirklich langsamer - aber konsequent.

Als pro naasking Antwort -, ist-und-Darsteller-oder ist-und-wie sind die beiden so schnell wie wie-und-null-check mit modernen JITs, wie gezeigt, durch den folgenden code:

using System;
using System.Diagnostics;
using System.Linq;

class Test
{
    const int Size = 30000000;

    static void Main()
    {
        object[] values = new object[Size];
        for (int i = 0; i < Size - 2; i += 3)
        {
            values[i] = null;
            values[i + 1] = "x";
            values[i + 2] = new object();
        }
        FindLengthWithIsAndCast(values);
        FindLengthWithIsAndAs(values);
        FindLengthWithAsAndNullCheck(values);
    }

    static void FindLengthWithIsAndCast(object[] values)        
    {
        Stopwatch sw = Stopwatch.StartNew();
        int len = 0;
        foreach (object o in values)
        {
            if (o is string)
            {
                string a = (string) o;
                len += a.Length;
            }
        }
        sw.Stop();
        Console.WriteLine("Is and Cast: {0} : {1}", len,
                          (long)sw.ElapsedMilliseconds);
    }

    static void FindLengthWithIsAndAs(object[] values)        
    {
        Stopwatch sw = Stopwatch.StartNew();
        int len = 0;
        foreach (object o in values)
        {
            if (o is string)
            {
                string a = o as string;
                len += a.Length;
            }
        }
        sw.Stop();
        Console.WriteLine("Is and As: {0} : {1}", len,
                          (long)sw.ElapsedMilliseconds);
    }

    static void FindLengthWithAsAndNullCheck(object[] values)        
    {
        Stopwatch sw = Stopwatch.StartNew();
        int len = 0;
        foreach (object o in values)
        {
            string a = o as string;
            if (a != null)
            {
                len += a.Length;
            }
        }
        sw.Stop();
        Console.WriteLine("As and null check: {0} : {1}", len,
                          (long)sw.ElapsedMilliseconds);
    }
}

Auf meinem laptop, alle diese führen in etwa 60ms. Zwei Dinge zu beachten:

• Es gibt keinen signifikanten Unterschied zwischen Ihnen. (In der Tat, es gibt Situationen, in denen die as-plus-null-check definitiv ist langsamer. Der obige code macht eigentlich der Typ das einfach, weil es für eine versiegelte Klasse; wenn Sie die Prüfung für eine Schnittstelle, die balance-Tipps leicht zu Gunsten der als-plus-null-check.)
• Sie sind alle wahnsinnig schnell. Diese einfach nicht der Flaschenhals im code, es sei denn, Sie wirklich nicht tun alles mit den Werten danach.

Lassen Sie uns also keine sorgen über die Leistung. Kümmern wir uns also über die Richtigkeit und Konsistenz.

Ich behaupte, dass ist-und-cast (oder-und -) sind beide unsicher beim Umgang mit Variablen, wie die Art des Wertes bezieht, es kann sich ändern, wegen einem anderen thread zwischen dem test und dem cast. Das wäre eine ziemlich seltene situation - aber ich hätte lieber eine Konvention, die ich verwenden können, konsequent.

Ich behaupte auch, dass die als-dann-null-check ermöglicht eine bessere Trennung von Bedenken. Wir haben eine Anweisung, die versucht, eine Umwandlung, und dann noch eine Anweisung, die verwendet das Ergebnis. Die ist-und-Darsteller-oder ist-und-wie führt einen test und dann ein weiterer Versuch, konvertieren Sie den Wert.

Anders ausgedrückt, würde jemand immer schreiben:

int value;
if (int.TryParse(text, out value))
{
    value = int.Parse(text);
    //Use value
}

Dass die Art dessen, was ist-und-Darsteller zu tun - obwohl natürlich in einer eher billiger Weg.

InformationsquelleAutor der Antwort Jon Skeet

Hier ist eine weitere Antwort, mit einigen IL-Vergleich. Betrachten Sie die Klasse:

public class MyClass
{
    public static void Main()
    {
        //Call the 2 methods
    }

    public void DirectCast(Object obj)
    {
        if ( obj is MyClass)
        { 
            MyClass myclass = (MyClass) obj; 
            Console.WriteLine(obj);
        } 
    } 


    public void UsesAs(object obj) 
    { 
        MyClass myclass = obj as MyClass; 
        if (myclass != null) 
        { 
            Console.WriteLine(obj);
        } 
    }
}

Schauen Sie sich jetzt den IL jede Methode produziert. Auch wenn die op-codes bedeuten nichts für Sie, können Sie sehen, mit einem großen Unterschied - isinst genannt wird, gefolgt von castclass in der DirectCast Methode. So zwei Aufrufe statt einem im Grunde.

.method public hidebysig instance void  DirectCast(object obj) cil managed
{
  //Code size       22 (0x16)
  .maxstack  8
  IL_0000:  ldarg.1
  IL_0001:  isinst     MyClass
  IL_0006:  brfalse.s  IL_0015
  IL_0008:  ldarg.1
  IL_0009:  castclass  MyClass
  IL_000e:  pop
  IL_000f:  ldarg.1
  IL_0010:  call       void [mscorlib]System.Console::WriteLine(object)
  IL_0015:  ret
} //end of method MyClass::DirectCast

.method public hidebysig instance void  UsesAs(object obj) cil managed
{
  //Code size       17 (0x11)
  .maxstack  1
  .locals init (class MyClass V_0)
  IL_0000:  ldarg.1
  IL_0001:  isinst     MyClass
  IL_0006:  stloc.0
  IL_0007:  ldloc.0
  IL_0008:  brfalse.s  IL_0010
  IL_000a:  ldarg.1
  IL_000b:  call       void [mscorlib]System.Console::WriteLine(object)
  IL_0010:  ret
} //end of method MyClass::UsesAs

Der isinst Schlüsselwort gegen die castclass

In diesem blog-post hat einen angemessenen Vergleich zwischen den beiden Möglichkeiten, es zu tun. Seine Zusammenfassung ist:

• Im direkten Vergleich, isinst ist schneller als castclass (zwar nur leicht)
• , Wenn die Prüfungen durchführen, um sicherzustellen, dass die Konvertierung erfolgreich war, isinst war deutlich schneller als castclass
• Eine Kombination von isinst und castclass sollte nicht verwendet werden, da dies viel langsamer als der Schnellste "sicher" Konvertierung (über 12% langsamer)

Ich persönlich benutze immer So, denn es ist leicht zu Lesen und empfohlen von der .NET-Entwicklungs-team (oder Jeffrey Richter sowieso)

InformationsquelleAutor der Antwort Chris S

als nie eine Ausnahme auslöst, wenn es nicht die Konvertierung der Rückkehr null statt (als arbeitet auf Referenz-Arten). Also mit als ist im Grunde gleichwertig zum

_myCls2 = _myObj is MyClass ? (MyClass)_myObj : null;

C-style-casts, auf der anderen Seite, werfen eine Ausnahme, wenn keine Konvertierung möglich ist.

InformationsquelleAutor der Antwort Anton Gogolev

Bitte ignorieren Jon Skeet Beratung, re:vermeiden Sie das testen-und-cast-Muster, dh.:

if (randomObject is TargetType)
{
    TargetType foo = randomObject as TargetType;
    //Do something with foo
}

Die Idee, dass dies mehr kostet, als eine Besetzung und einen null-test ist ein MYTHOS:

TargetType convertedRandomObject = randomObject as TargetType;
if (convertedRandomObject != null)
{
    //Do stuff with convertedRandomObject
}

Es ist eine Mikro-Optimierung, das funktioniert nicht. Ich lief einige echte tests, und testen-und-cast ist tatsächlich schneller als cast-und-null-Vergleich, und es ist sicherer, auch, weil Sie nicht über die Möglichkeit mit einem null-Verweis in den Bereich außerhalb der wenn sollte der cast fehl.

Wenn Sie möchten, einen Grund, warum die test-und die Umwandlung ist schneller oder zumindest nicht langsamer, gibt es eine einfache und komplexe Grund.

Einfach: auch naiv-Compiler verschmelzen zwei ähnliche Operationen, wie zum Beispiel test-und-Darsteller, in einem einzigen test und Verzweigung. cast-und-null-test zwingen können, zwei tests und ein Zweig, eine für die Typprüfung und-Konvertierung auf null Fehler, eine für die null-check selbst. Zumindest, werden Sie beide zu optimieren, um einen einzelnen test und Verzweigung, so dass test-and-cast wäre weder langsamer noch schneller als cast-und-null-test.

Komplex: warum test-und cast ist schneller: cast-und-null-test stellt eine weitere variable in den äußeren Umfang, das muss der compiler track für ausführen, um liveness, und es kann nicht in der Lage zu optimieren der Weg, die variable, je nachdem wie Komplex dein control-flow ist. Umgekehrt, test-und-cast stellt eine neue variable, die nur in einem begrenzten Umfang, so weiß der compiler, dass die variable dead nach dem Umfang beendet, und so optimieren können, registrieren Zuordnung besser.

Also bitte, BITTE lass dieses "cast-und-null-test ist besser als der test-and-cast" Beratung STERBEN. BITTE. test-und-cast ist sowohl sicherer und schneller.

InformationsquelleAutor der Antwort naasking

Dies ist nicht eine Antwort auf die Frage, aber Kommentar auf die Frage code-Beispiel:

In der Regel sollten Sie nicht über zu werfen Sie ein Objekt aus, z.B. IMyInterface zu MyClass. Die große Sache über Schnittstellen ist, dass wenn man ein Objekt als Eingabe, die eine Schnittstelle implementiert, als Sie nicht zu kümmern, welche Art von Objekt Sie bekommen.

Wenn Sie die Umwandlung IMyInterface, MyClass, als Sie schon davon ausgehen, dass Sie erhalten ein Objekt vom Typ MyClass und es macht keinen Sinn, IMyInterface, weil, wenn Sie füttern Sie Ihren code mit anderen Klassen, die IMyInterface implementieren, es würde brechen, dein code...

Nun, mein Rat: wenn Ihre Oberflächen sind gut gestaltet, Sie können vermeiden, eine Menge von typecasting.

InformationsquelleAutor der Antwort f3lix

Meine Antwort ist nur eine Frage der Geschwindigkeit in den Fällen, wenn wir nicht überprüfen Sie den Typ und wir überprüfen Sie nicht null-Werte nach dem Gießen. Ich fügte zwei zusätzliche tests, um Jon Skeet code:

using System;
using System.Diagnostics;

class Test
{
    const int Size = 30000000;

    static void Main()
    {
        object[] values = new object[Size];

        for (int i = 0; i < Size; i++)
        {
            values[i] = "x";
        }
        FindLengthWithIsAndCast(values);
        FindLengthWithIsAndAs(values);
        FindLengthWithAsAndNullCheck(values);

        FindLengthWithCast(values);
        FindLengthWithAs(values);

        Console.ReadLine();
    }

    static void FindLengthWithIsAndCast(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int len = 0;
        foreach (object o in values)
        {
            if (o is string)
            {
                string a = (string)o;
                len += a.Length;
            }
        }
        sw.Stop();
        Console.WriteLine("Is and Cast: {0} : {1}", len,
                          (long)sw.ElapsedMilliseconds);
    }

    static void FindLengthWithIsAndAs(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int len = 0;
        foreach (object o in values)
        {
            if (o is string)
            {
                string a = o as string;
                len += a.Length;
            }
        }
        sw.Stop();
        Console.WriteLine("Is and As: {0} : {1}", len,
                          (long)sw.ElapsedMilliseconds);
    }

    static void FindLengthWithAsAndNullCheck(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int len = 0;
        foreach (object o in values)
        {
            string a = o as string;
            if (a != null)
            {
                len += a.Length;
            }
        }
        sw.Stop();
        Console.WriteLine("As and null check: {0} : {1}", len,
                          (long)sw.ElapsedMilliseconds);
    }
    static void FindLengthWithCast(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int len = 0;
        foreach (object o in values)
        {
            string a = (string)o;
            len += a.Length;
        }
        sw.Stop();
        Console.WriteLine("Cast: {0} : {1}", len,
                          (long)sw.ElapsedMilliseconds);
    }

    static void FindLengthWithAs(object[] values)
    {
        Stopwatch sw = Stopwatch.StartNew();
        int len = 0;
        foreach (object o in values)
        {
            string a = o as string;
            len += a.Length;
        }
        sw.Stop();
        Console.WriteLine("As: {0} : {1}", len,
                          (long)sw.ElapsedMilliseconds);
    }
}

Ergebnis:

Is and Cast: 30000000 : 88
Is and As: 30000000 : 93
As and null check: 30000000 : 56
Cast: 30000000 : 66
As: 30000000 : 46

Versuchen Sie nicht, den Fokus auf die Geschwindigkeit haben (wie ich), da ist dies alles sehr sehr schnell.

InformationsquelleAutor der Antwort CoperNick

Wenn Sie die Office-PIAs-targeting .NET Framework 4.X verwenden Sie die als Schlüsselwort, da es sonst nicht kompiliert.

Microsoft.Office.Interop.Outlook.Application o = new Microsoft.Office.Interop.Outlook.Application();
Microsoft.Office.Interop.Outlook.MailItem m = o.CreateItem(Microsoft.Office.Interop.Outlook.OlItemType.olMailItem) as Microsoft.Office.Interop.Outlook.MailItem;

Casting ist OK, wenn die Ausrichtung .NET 2.0 allerdings:

Microsoft.Office.Interop.Outlook.MailItem m = (Microsoft.Office.Interop.Outlook.MailItem)o.CreateItem(Microsoft.Office.Interop.Outlook.OlItemType.olMailItem);

Beim anvisieren .NET 4.X die Fehler sind:

Fehler CS0656: Fehlende compiler erforderlich Mitglied " Microsoft.CSharp.RuntimeBinder.Binder.Convert"

Fehler CS0656: Fehlende compiler erforderlich Mitglied " Microsoft.CSharp.RuntimeBinder.CSharpArgumentInfo.Erstellen Sie"

InformationsquelleAutor der Antwort Olivier MATROT

Was Sie wählen, hängt stark von, was erforderlich ist.
Ich bevorzuge die explizite Umwandlung

IMyInterface = (IMyInterface)someobj;

weil, wenn das Objekt sollte von der IMyInterface Typ und es ist nicht - es ist definitiv ein problem.
Es ist besser, Fehler so früh wie möglich, da die genauen Fehler behoben werden, anstatt die Festsetzung der Nebenwirkung.

Aber, wenn Sie sich mit Methoden, die akzeptiert object als parameter, dann müssen Sie prüfen Ihre genauen Typ vor ausführen von code. In einem solchen Fall as würde nützlich sein, so können Sie vermeiden InvalidCastException.

InformationsquelleAutor der Antwort Oleg

Haben Sie einen Blick auf diese links:

• http://gen5.info/q/2008/06/13/prefix-casting-versus-as-casting-in-c/
• http://www.codeproject.com/Articles/8052/Type-casting-impact-over-execution-performance-in

zeigen Sie Ihnen einige details und performance-tests.

InformationsquelleAutor der Antwort juFo