Приведение против использования ключевого слова as в CLR

При программировании интерфейсов, я обнаружил, что я часто использую приведение типов или преобразование типов объектов.

Есть ли разница между этими двумя методами конвертации? Если да, то есть ли разница в стоимости или как это повлияет на мою программу?

public interface IMyInterface
{
    void AMethod();
}

public class MyClass : IMyInterface
{
    public void AMethod()
    {
       //Do work
    }

    // Other helper methods....
}

public class Implementation
{
    IMyInterface _MyObj;
    MyClass _myCls1;
    MyClass _myCls2;

    public Implementation()
    {
        _MyObj = new MyClass();

        // What is the difference here:
        _myCls1 = (MyClass)_MyObj;
        _myCls2 = (_MyObj as MyClass);
    }
}

Кроме того, что является "вообще" предпочтительным методом?

Ответ под строкой был написан в 2008 году.

В C # 7 введено сопоставление с образцом, которое в значительной степени заменило asоператор, теперь вы можете написать:

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

Обратите внимание, что ttпосле этого он все еще находится в области действия, но не определенно назначен. (Это является определенно присвоенной в ifтеле). Это немного раздражает в некоторых случаях, так что если вы действительно заботитесь о введении наименьшее число переменных , возможных в любой области видимости, вы все равно можете использовать с isпоследующим броском.

Я не думаю, что какие-либо ответы до сих пор (во время запуска этого ответа!) Действительно объяснили, где и какой стоит использовать.

• Не делай этого:

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

  Это не только проверка дважды, но и проверка разных вещей, если randomObjectэто поле, а не локальная переменная. Возможно, что «если» пройдет, но приведение не будет выполнено, если другой поток изменит значение randomObjectмежду ними.

• Если randomObjectдействительно должен быть экземпляр TargetType, то есть, если это не так, это означает, что есть ошибка, тогда приведение является правильным решением. Это немедленно вызывает исключение, что означает, что больше нет работы при неправильных предположениях, и исключение правильно показывает тип ошибки.

  // 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;

• Если randomObject может быть экземпляром TargetTypeи TargetTypeявляется ссылочным типом, используйте код, подобный следующему:

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

• Если randomObject может быть экземпляром TargetTypeи TargetTypeявляется типом значения, то мы не можем использовать asс TargetTypeсамим собой, но мы можем использовать обнуляемый тип:

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

  (Примечание: в настоящее время это на самом деле медленнее, чем + + cast . Я думаю, что это более элегантно и последовательно, но мы здесь.)

• Если вам действительно не нужно преобразованное значение, но вам просто нужно знать, является ли оно экземпляром TargetType, тогда isоператор - ваш друг. В этом случае не имеет значения, является ли TargetType ссылочным типом или типом значения.

• Могут быть и другие случаи использования дженериков, где isэто полезно (потому что вы можете не знать, является ли T ссылочным типом или нет, поэтому вы не можете использовать как), но они относительно неясны.

• Я почти наверняка использовал isдля случая значения типа до сих пор, не думая об использовании обнуляемого типа и asвместе :)

РЕДАКТИРОВАТЬ: Обратите внимание, что ни один из вышеперечисленных не говорит о производительности, кроме случая типа значения, где я заметил, что распаковка в тип значения, допускающий значение NULL, на самом деле медленнее - но согласованно.

В соответствии с ответом Нааскинга, is-and-cast или is-and-as являются такими же быстрыми, как и нулевая проверка с современными JIT, как показано кодом ниже:

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);
    }
}

На моем ноутбуке все это выполняется примерно за 60 мс. Обратите внимание на две вещи:

• Там нет значительной разницы между ними. (На самом деле, есть ситуации , в которых , как плюс нуль-проверка , безусловно , является медленнее , приведенный выше код на самом деле делает проверку типа легко , потому что это для герметичного класса;. , Если вы проверяете для интерфейса, балансовые советы немного в пользу как-плюс-ноль-чек.)
• Они все безумно быстрые. Это просто не будет узким местом в вашем коде, если вы действительно не собираетесь ничего делать со значениями впоследствии.

Так что давайте не будем беспокоиться о производительности. Давайте позаботимся о правильности и последовательности.

Я утверждаю, что is-and-cast (или is-and-as) небезопасны при работе с переменными, так как тип значения, на которое он ссылается, может измениться из-за другого потока между тестом и приведением. Это было бы довольно редкой ситуацией - но я бы предпочел соглашение, которое я могу использовать последовательно.

Я также утверждаю, что проверка «как тогда ноль» дает лучшее разделение проблем. У нас есть одно утверждение, которое пытается преобразовать, а затем одно утверждение, которое использует результат. Метод is-and-cast или is-and-as выполняет тест, а затем еще одну попытку преобразовать значение.

Другими словами, кто- нибудь написал бы:

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

Это своего рода то, что делает актерский состав - хотя, очевидно, более дешевым способом.

«as» вернет NULL, если невозможно разыграть.

кастинг до поднимет исключение.

Для производительности повышение исключения обычно более затратно во времени.

Вот еще один ответ, с некоторым сравнением IL. Рассмотрим класс:

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);
        } 
    }
}

Теперь посмотрим на IL, который выдает каждый метод. Даже если операционные коды ничего не значат для вас, вы можете увидеть одно существенное отличие - вызывается isinst, за которым следует castclass в методе DirectCast. Так что два звонка вместо одного в принципе.

.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

Ключевое слово isinst по сравнению с кастклассом

В этом посте есть достойное сравнение двух способов сделать это. Его резюме:

• В прямом сравнении isinst быстрее Castclass (хотя и незначительно)
• Когда необходимо выполнить проверку, чтобы убедиться, что преобразование прошло успешно, isinst был значительно быстрее, чем castclass
• Не следует использовать комбинацию isinst и castclass, так как она была намного медленнее, чем самая быстрая «безопасная» конверсия (более чем на 12% медленнее)

Лично я всегда использую как, потому что это легко читать и рекомендуется командой разработчиков .NET (или Джеффри Рихтер в любом случае)

Одно из более тонких различий между ними заключается в том, что ключевое слово «as» нельзя использовать для приведения, когда задействован оператор приведения:

public class Foo
{
    public string Value;

    public static explicit operator string(Foo f)
    {
        return f.Value;
    }

}

public class Example
{
    public void Convert()
    {
        var f = new Foo();
        f.Value = "abc";

        string cast = (string)f;
        string tryCast = f as string;
    }
}

Это не скомпилирует (хотя я думаю, что это было в предыдущих версиях) в последней строке, так как ключевые слова «как» не принимают во внимание операторы приведения. Линия string cast = (string)f;работает просто отлично, хотя.

as никогда не выдает исключение, если не может выполнить преобразование, возвращающее ноль вместо этого ( поскольку работает только со ссылочными типами). Таким образом, использование как в основном эквивалентно

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

С другой стороны, приведения в стиле C выдает исключение, когда преобразование невозможно.

Не совсем ответ на ваш вопрос, но я думаю, что это важный связанный вопрос.

Если вы программируете на интерфейс, вам не нужно создавать каст. Надеюсь, эти броски очень редки. Если нет, то вам, вероятно, нужно переосмыслить некоторые из ваших интерфейсов.

Пожалуйста, не обращайте внимания на советы Джона Скита: избегайте шаблонов «тест-и-бросок», т.е.

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

Идея, что это стоит больше, чем приведение и нулевой тест, является МИФОМ :

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

Это микрооптимизация, которая не работает. Я выполнил несколько реальных тестов , и тестирование-и-приведение на самом деле быстрее, чем сравнение-и-ноль-сравнение, и это также безопаснее, потому что у вас нет возможности иметь нулевую ссылку в области действия вне приведения. потерпеть поражение.

Если вам нужна причина, почему тестирование и приведение происходит быстрее или, по крайней мере, не медленнее, есть простая и сложная причина.

Все просто: даже наивные компиляторы объединят две одинаковые операции, такие как test-and-cast, в один тест и ветвь. cast-and-null-test может вызвать два теста и ветвь, один для проверки типа и преобразования в null при ошибке, один для самой проверки null. По крайней мере, они оба будут оптимизированы для одного теста и ветвления, поэтому тестирование и приведение не будут ни медленнее, ни быстрее, чем приведение и приведение к нулю.

Сложно: почему тестирование и приведение происходит быстрее: метод «бросить и обнулить» вводит во внешнюю область видимости другую переменную, которую компилятор должен отслеживать для обеспечения жизнеспособности, и он может не иметь возможности оптимизировать эту переменную в зависимости от сложности вашего управления. поток есть. И наоборот, тестирование и приведение вводят новую переменную только в области с разделителями, поэтому компилятор знает, что переменная устарела после выхода из области, и поэтому может лучше оптимизировать распределение регистров.

Поэтому, пожалуйста, ПОЖАЛУЙСТА, пусть этот «бросок-и-ноль-проверка лучше, чем проверка-и-бросок» совет DIE. ПОЖАЛУЙСТА. Тестирование и приведение более безопасны и быстрее.

Если приведение не выполнено, ключевое слово as не вызывает исключение; вместо этого он устанавливает переменную в null (или в значение по умолчанию для типов значений).

Это не ответ на вопрос, а комментарий к примеру кода вопроса:

Обычно вам не нужно приводить объект из, например, IMyInterface в MyClass. Самое замечательное в интерфейсах состоит в том, что если вы берете объект в качестве входных данных, который реализует интерфейс, то вам не нужно заботиться о том, какой объект вы получаете.

Если вы приведете IMyInterface к MyClass, то вы уже предполагаете, что получаете объект типа MyClass, и нет смысла использовать IMyInterface, потому что если вы передадите свой код другим классам, которые реализуют IMyInterface, это нарушит ваш код ...

Теперь мой совет: если ваши интерфейсы хорошо спроектированы, вы можете избежать большого количества типов.

asОператор может быть использован только на ссылочные типы, не могут быть перегружены, и он вернется , nullесли операция не выполняется. Это никогда не бросит исключение.

Приведение может использоваться для любых совместимых типов, оно может быть перегружено, и оно выдаст исключение в случае сбоя операции.

Выбор того, что использовать, зависит от обстоятельств. Прежде всего, это вопрос того, хотите ли вы выдать исключение при неудачном преобразовании.

Мой ответ касается только скорости в тех случаях, когда мы не проверяем тип и не проверяем нули после приведения. Я добавил два дополнительных теста в код Джона Скита:

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);
    }
}

Результат:

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

Не пытайтесь сосредоточиться на скорости (как я), потому что все это очень, очень быстро.

Помимо всего того, что уже было здесь раскрыто, я натолкнулся на практическую разницу, которую, я думаю, стоит отметить, между явным приведением

var x = (T) ...

по сравнению с использованием asоператора.

Вот пример:

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine(GenericCaster<string>(12345));
        Console.WriteLine(GenericCaster<object>(new { a = 100, b = "string" }) ?? "null");
        Console.WriteLine(GenericCaster<double>(20.4));

        //prints:
        //12345
        //null
        //20.4

        Console.WriteLine(GenericCaster2<string>(12345));
        Console.WriteLine(GenericCaster2<object>(new { a = 100, b = "string" }) ?? "null");

        //will not compile -> 20.4 does not comply due to the type constraint "T : class"
        //Console.WriteLine(GenericCaster2<double>(20.4));
    }

    static T GenericCaster<T>(object value, T defaultValue = default(T))
    {
        T castedValue;
        try
        {
            castedValue = (T) Convert.ChangeType(value, typeof(T));
        }
        catch (Exception)
        {
            castedValue = defaultValue;
        }

        return castedValue;
    }

    static T GenericCaster2<T>(object value, T defaultValue = default(T)) where T : class
    {
        T castedValue;
        try
        {
            castedValue = Convert.ChangeType(value, typeof(T)) as T;
        }
        catch (Exception)
        {
            castedValue = defaultValue;
        }

        return castedValue;
    }
}

Итог: GenericCaster2 не будет работать с типами структуры. GenericCaster будет.

Если вы используете Office PIA для .NET Framework 4.X, вам следует использовать ключевое слово as , иначе оно не будет компилироваться.

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;

Кастинг в порядке при нацеливании на .NET 2.0, хотя:

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

При нацеливании на .NET 4.X возникают следующие ошибки:

ошибка CS0656: отсутствует требуемый для компилятора элемент 'Microsoft.CSharp.RuntimeBinder.Binder.Convert'

ошибка CS0656: отсутствует требуемый компилятор элемент 'Microsoft.CSharp.RuntimeBinder.CSharpArgumentInfo.Create'

asКлючевое слово работает так же , как явное приведение между совместимыми ссылочными типами с основным отличием , что он не вызывает исключение , если преобразование не удалось. Скорее, он возвращает нулевое значение в целевой переменной. Поскольку исключения очень дороги с точки зрения производительности, это считается гораздо лучшим методом приведения.

То, что вы выбираете, сильно зависит от того, что требуется. Я предпочитаю явное приведение

IMyInterface = (IMyInterface)someobj;

потому что если объект должен иметь тип IMyInterface, а это не так - это определенно проблема. Лучше получить ошибку как можно раньше, потому что точная ошибка будет исправлена, а не устранение ее побочного эффекта.

Но если вы имеете дело с методами, которые принимают в objectкачестве параметра, вам нужно проверить его точный тип перед выполнением любого кода. В таком случае asбыло бы полезно, чтобы вы могли избежать InvalidCastException.

Это зависит от того, хотите ли вы проверить на null после использования «как» или вы бы предпочли, чтобы ваше приложение выдало исключение?

Мое эмпирическое правило: если я всегда ожидаю, что переменная будет того типа, которого я ожидаю в то время, когда я хочу, я использую приведение. Если возможно, что переменная не будет приведена к тому, что я хочу, и я готов обработать пустые значения от использования как, я буду использовать как.

Посмотрите на эти ссылки:

• 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

они показывают вам некоторые детали и тесты производительности.

Проблема ОП ограничена конкретной ситуацией. Название охватывает гораздо больше ситуаций.
Вот краткий обзор всех соответствующих ситуаций приведения, о которых я сейчас могу думать:

private class CBase
{
}

private class CInherited : CBase
{
}

private enum EnumTest
{
  zero,
  one,
  two
}

private static void Main (string[] args)
{
  //########## classes ##########
  // object creation, implicit cast to object
  object oBase = new CBase ();
  object oInherited = new CInherited ();

  CBase oBase2 = null;
  CInherited oInherited2 = null;
  bool bCanCast = false;

  // explicit cast using "()"
  oBase2 = (CBase)oBase;    // works
  oBase2 = (CBase)oInherited;    // works
  //oInherited2 = (CInherited)oBase;   System.InvalidCastException
  oInherited2 = (CInherited)oInherited;    // works

  // explicit cast using "as"
  oBase2 = oBase as CBase;
  oBase2 = oInherited as CBase;
  oInherited2 = oBase as CInherited;  // returns null, equals C++/CLI "dynamic_cast"
  oInherited2 = oInherited as CInherited;

  // testing with Type.IsAssignableFrom(), results (of course) equal the results of the cast operations
  bCanCast = typeof (CBase).IsAssignableFrom (oBase.GetType ());    // true
  bCanCast = typeof (CBase).IsAssignableFrom (oInherited.GetType ());    // true
  bCanCast = typeof (CInherited).IsAssignableFrom (oBase.GetType ());    // false
  bCanCast = typeof (CInherited).IsAssignableFrom (oInherited.GetType ());    // true

  //########## value types ##########
  int iValue = 2;
  double dValue = 1.1;
  EnumTest enValue = EnumTest.two;

  // implicit cast, explicit cast using "()"
  int iValue2 = iValue;   // no cast
  double dValue2 = iValue;  // implicit conversion
  EnumTest enValue2 = (EnumTest)iValue;  // conversion by explicit cast. underlying type of EnumTest is int, but explicit cast needed (error CS0266: Cannot implicitly convert type 'int' to 'test01.Program.EnumTest')

  iValue2 = (int)dValue;   // conversion by explicit cast. implicit cast not possible (error CS0266: Cannot implicitly convert type 'double' to 'int')
  dValue2 = dValue;
  enValue2 = (EnumTest)dValue;  // underlying type is int, so "1.1" beomces "1" and then "one"

  iValue2 = (int)enValue;
  dValue2 = (double)enValue;
  enValue2 = enValue;   // no cast

  // explicit cast using "as"
  // iValue2 = iValue as int;   error CS0077: The as operator must be used with a reference type or nullable type
}