Przesyłanie vs. użycie słowa kluczowego „as” w CLR

Podczas programowania interfejsów odkryłem, że dużo rzucam lub przekształcam typy obiektów.

Czy istnieje różnica między tymi dwiema metodami konwersji? Jeśli tak, to czy istnieje różnica kosztów lub jak to wpływa na mój program?

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

Ponadto, jaka jest „ogólnie” preferowana metoda?

Odpowiedź poniżej linii została napisana w 2008 roku.

W C # 7 wprowadzono dopasowanie wzorca, które w dużej mierze zastąpiło asoperatora, ponieważ można teraz pisać:

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

Zauważ, że ttpo tym jest nadal w zasięgu, ale nie jest zdecydowanie przypisany. (Jest to zdecydowanie przypisane w ramachif ciele.) W niektórych przypadkach jest to nieco irytujące, więc jeśli naprawdę zależy ci na wprowadzeniu możliwie najmniejszej liczby zmiennych w każdym zakresie, możesz nadal chcieć użyć isrzutowania.

Nie sądzę, aby jakakolwiek z dotychczasowych odpowiedzi (w momencie rozpoczynania tej odpowiedzi!) Naprawdę wyjaśniała, gdzie warto jej użyć.

• Nie rób tego:

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

  Nie tylko sprawdza się to dwukrotnie, ale może sprawdzać różne rzeczy, jeśli randomObjectjest to pole, a nie zmienna lokalna. Możliwe jest, że „if” przejdzie, ale rzutowanie zakończy się niepowodzeniem, jeśli inny wątek zmieni wartośćrandomObject między nimi.

• Jeśli randomObjectnaprawdę powinno to być wystąpienie TargetType, tzn. Jeśli tak nie jest, oznacza to błąd, to casting jest właściwym rozwiązaniem. To natychmiast zgłasza wyjątek, co oznacza, że ​​nie wykonuje się żadnej pracy przy niepoprawnych założeniach, a wyjątek poprawnie pokazuje rodzaj błędu.

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

• Jeśli randomObject może to być instancja TargetTypei TargetTypejest typem odwołania, użyj kodu w następujący sposób:

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

• Jeśli randomObject może być instancją typu TargetTypei TargetTypejest typem wartości, nie możemy użyć go asrazem TargetType, ale możemy użyć typu zerowego:

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

  (Uwaga: obecnie jest to w rzeczywistości wolniejsze niż + cast . Myślę, że jest bardziej eleganckie i spójne, ale proszę bardzo.)

• Jeśli naprawdę nie potrzebujesz przekonwertowanej wartości, ale musisz tylko wiedzieć, czy jest to instancja TargetType, a następnieis operator jest Twoim przyjacielem. W tym przypadku nie ma znaczenia, czy TargetType jest typem referencyjnym czy typem wartości.

• Mogą wystąpić inne przypadki dotyczące leków generycznych is są użyteczne (ponieważ możesz nie wiedzieć, czy T jest typem referencyjnym, czy nie, więc nie możesz użyć jako), ale są one stosunkowo niejasne.

• Prawie na pewno wcześniej użyłem isprzypadku typu wartości, nie myśląc o użyciu typu zerowalnego i asrazem :)

EDYCJA: Zauważ, że żadne z powyższych nie mówi o wydajności, poza przypadkiem typu wartości, w którym zauważyłem, że rozpakowanie do typu wartości zerowej jest w rzeczywistości wolniejsze - ale spójne.

Zgodnie z odpowiedzią naasking, zarówno rzutowanie jak i rzucanie jest zarówno szybkie jak i zerowe przy pomocy nowoczesnych JIT, jak pokazano w poniższym kodzie:

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

Na moim laptopie wszystkie działają w około 60ms. Dwie rzeczy do zapamiętania:

• Nie ma między nimi znaczącej różnicy. (W rzeczywistości zdarzają się sytuacje, w których sprawdzenie „plus-zero” jest zdecydowanie wolniejsze. Powyższy kod w rzeczywistości ułatwia sprawdzanie typu, ponieważ dotyczy klasy zapieczętowanej; jeśli sprawdzasz interfejs, saldo lekko się przechyla na korzyść kontroli plus-zerowej).
• Wszystkie są niesamowicie szybkie. To po prostu nie będzie wąskim gardłem w kodzie, chyba że naprawdę nie zamierzasz nic robić z wartościami później.

Nie martwmy się więc o wydajność. Martwmy się o poprawność i spójność.

Uważam, że zarówno rzutowanie, jak i rzutowanie jest niebezpieczne w przypadku zmiennych, ponieważ rodzaj wartości, do której się odnosi, może się zmienić z powodu innego wątku między testem a rzutowaniem. To byłaby dość rzadka sytuacja - ale wolałbym mieć konwencję, z której mogę konsekwentnie korzystać.

Twierdzę również, że kontrola „jak wtedy-zero” zapewnia lepszy rozdział obaw. Mamy jedno zdanie, które próbuje przekształcić, a następnie jedno zdanie, które wykorzystuje wynik. Is-and-cast lub is-and-as wykonuje test, a następnie kolejną próbę konwersji wartości.

Innymi słowy, czy ktoś kiedykolwiek napisałby:

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

Tak właśnie się dzieje - choć oczywiście w tańszy sposób.

„as” zwróci NULL, jeśli nie będzie możliwe przesłanie.

rzucanie wcześniej spowoduje wyjątek.

W przypadku wydajności zgłoszenie wyjątku jest zwykle bardziej kosztowne w czasie.

Oto kolejna odpowiedź, z pewnym porównaniem IL. Rozważ klasę:

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

Teraz spójrz na IL, którą wytwarza każda metoda. Nawet jeśli kody operacyjne nic dla ciebie nie znaczą, możesz zauważyć jedną zasadniczą różnicę - wywoływana jest isinst, po której następuje castclass w metodzie DirectCast. Więc dwa połączenia zamiast jednego w zasadzie.

.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

Słowo kluczowe isinst vs. castclass

Ten post na blogu zawiera przyzwoite porównanie dwóch sposobów. Jego streszczenie to:

• W bezpośrednim porównaniu, isinst jest szybszy niż castclass (choć tylko nieznacznie)
• Gdy trzeba było sprawdzić, czy konwersja się powiodła, isinst był znacznie szybszy niż klasa Cast Cast
• Nie należy używać kombinacji isinst i castclass, ponieważ było to znacznie wolniejsze niż najszybsza „bezpieczna” konwersja (ponad 12% wolniej)

Ja osobiście zawsze używam As, ponieważ jest łatwy do odczytania i jest zalecany przez zespół programistów .NET (lub Jeffrey Richter i tak)

Jedną z bardziej subtelnych różnic między nimi jest to, że słowa kluczowego „as” nie można używać do rzutowania, gdy zaangażowany jest operator rzutowania:

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

Nie kompiluje się (chociaż myślę, że tak było w poprzednich wersjach) w ostatnim wierszu, ponieważ słowa kluczowe „as” nie uwzględniają operatorów rzutowania. Linia string cast = (string)f;działa jednak dobrze.

as nigdy nie zgłasza wyjątku, jeśli nie może zamiast tego wykonać konwersji zwracając null ( ponieważ działa tylko na typach referencyjnych). Więc użycie as jest w zasadzie równoważne z

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

Natomiast rzutki w stylu C rzucają wyjątek, gdy konwersja nie jest możliwa.

Nie do końca odpowiedź na twoje pytanie, ale to, co uważam za ważny powiązany punkt.

Jeśli programujesz do interfejsu, nie powinno być potrzeby przesyłania. Mam nadzieję, że te obsady są bardzo rzadkie. Jeśli nie, prawdopodobnie musisz ponownie przemyśleć niektóre interfejsy.

Proszę zignorować rady Jona Skeeta, a mianowicie: unikać wzorca testowania i rzucania, tj .:

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

Pomysł, że kosztuje to więcej niż rzut i test zerowy, to MIT :

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

To mikrooptymalizacja, która nie działa. Przeprowadziłem kilka prawdziwych testów , a testowanie i przesyłanie jest w rzeczywistości szybsze niż porównanie rzutowania i zerowania, a także jest bezpieczniejsze, ponieważ nie masz możliwości posiadania pustego odwołania w zakresie poza rzutowaniem zawieść.

Jeśli chcesz mieć powód, dla którego testowanie i przesyłanie jest szybsze lub przynajmniej wolniejsze, istnieje prosty i złożony powód.

Proste: nawet naiwne kompilatory połączą dwie podobne operacje, takie jak testowanie i odlewanie, w jeden test i gałąź. test cast-and-null może wymusić dwa testy i odgałęzienie, jeden dla testu typu i konwersji na zero w przypadku niepowodzenia, jeden dla samego sprawdzenia null. Przynajmniej obie zoptymalizują się do pojedynczego testu i gałęzi, więc testowanie i rzucanie nie byłoby ani wolniejsze, ani szybsze niż rzutowanie i zerowanie.

Złożona: dlaczego testowanie i rzutowanie jest szybsze: testowanie rzutowe i zerowe wprowadza kolejną zmienną do zakresu zewnętrznego, którą kompilator musi śledzić pod kątem żywotności, i może nie być w stanie zoptymalizować tej zmiennej w zależności od stopnia złożoności kontroli przepływ jest. I odwrotnie, test-and-cast wprowadza nową zmienną tylko w ograniczonym zakresie, dzięki czemu kompilator wie, że zmienna jest martwa po wyjściu z zakresu, a zatem może lepiej zoptymalizować alokację rejestru.

PROSZĘ więc, niech ten „test„ rzuć i zeruj ”jest lepszy niż„ testuj i odrzuć ”poradę DIE. PROSZĘ. test-and-cast jest zarówno bezpieczniejszy, jak i szybszy.

Jeśli rzutowanie się nie powiedzie, słowo kluczowe „as” nie zgłasza wyjątku; zamiast tego ustawia zmienną na null (lub na wartość domyślną dla typów wartości).

To nie jest odpowiedź na pytanie, ale komentarz do przykładu kodu pytania:

Zwykle nie trzeba rzutować obiektu z np. IMyInterface na MyClass. Wspaniałą rzeczą w interfejsach jest to, że jeśli weźmiesz obiekt jako dane wejściowe, które implementuje interfejs, nie musisz się martwić, jaki rodzaj obiektu otrzymujesz.

Jeśli rzucisz IMyInterface na MyClass, to już zakładasz, że otrzymujesz obiekt typu MyClass i nie ma sensu używać IMyInterface, ponieważ jeśli karmisz swój kod innymi klasami, które implementują IMyInterface, spowoduje to uszkodzenie twojego kodu ...

Teraz moja rada: jeśli twoje interfejsy są dobrze zaprojektowane, możesz uniknąć wielu rzutów.

asOperator może być używany tylko w typach referencyjnych, to nie może być przeciążona, a powróci null, jeśli operacja się nie powiedzie. Nigdy nie rzuci wyjątku.

Przesyłanie może być zastosowane na dowolnym kompatybilnym typie, może być przeciążone i spowoduje wyjątek, jeśli operacja się nie powiedzie.

Wybór zastosowania zależy od okoliczności. Przede wszystkim chodzi o to, czy chcesz zgłosić wyjątek w przypadku nieudanej konwersji.

Moja odpowiedź dotyczy tylko prędkości w przypadkach, gdy nie sprawdzamy typu i nie sprawdzamy wartości zerowych po rzuceniu. Dodałem dwa dodatkowe testy do kodu Jona Skeeta:

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

Wynik:

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

Nie próbuj koncentrować się na szybkości (tak jak ja), ponieważ wszystko to jest bardzo szybkie.

Oprócz wszystkiego, co już tu ujawniłem, właśnie natrafiłem na praktyczną różnicę, którą moim zdaniem warto zauważyć, między jawnym castingiem

var x = (T) ...

w porównaniu z użyciem as operatora.

Oto przykład:

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

Konkluzja: GenericCaster2 nie będzie działać z typami struktur. GenericCaster będzie.

W przypadku korzystania z pakietu Office PIA kierowania .NET Framework 4.X należy użyć jako hasła, w przeciwnym razie nie będzie skompilować.

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;

Przesyłanie jest jednak prawidłowe podczas celowania w .NET 2.0:

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

Podczas celowania w .NET 4.X błędy to:

błąd CS0656: Brak wymaganego kompilatora członek „Microsoft.CSharp.RuntimeBinder.Binder.Convert”

błąd CS0656: Brak wymaganego kompilatora element członkowski „Microsoft.CSharp.RuntimeBinder.CSharpArgumentInfo.Create”

Słowo askluczowe działa tak samo, jak jawne rzutowanie między zgodnymi typami referencyjnymi, z tą różnicą, że nie powoduje wyjątku w przypadku niepowodzenia konwersji. Daje raczej wartość zerową w zmiennej docelowej. Ponieważ wyjątki są bardzo drogie pod względem wydajności, uważa się je za znacznie lepszą metodę odlewania.

To, co wybierzesz, zależy od tego, co jest wymagane. Wolę jawne castingi

IMyInterface = (IMyInterface)someobj;

ponieważ jeśli obiekt powinien być typu IMyInterface, a nie jest - to zdecydowanie problem. Lepiej jest otrzymać błąd jak najwcześniej, ponieważ dokładny błąd zostanie naprawiony zamiast naprawiać jego efekt uboczny.

Ale jeśli masz do czynienia z metodami, które akceptują objectjako parametr, musisz sprawdzić jego dokładny typ przed wykonaniem jakiegokolwiek kodu. W takim przypadku asprzydatne byłoby uniknięcie InvalidCastException.

Zależy, czy po sprawdzeniu „as” chcesz sprawdzić wartość null, czy wolisz, aby aplikacja zgłosiła wyjątek?

Moją ogólną zasadą jest, jeśli zawsze oczekuję, że zmienna będzie typu, którego oczekuję w momencie, gdy chcę użyć rzutowania. Jeśli możliwe jest, że zmienna nie będzie rzutować na to, czego chcę i jestem przygotowany do obsługi wartości zerowych przy użyciu as, użyję jako.

Spójrz na te linki:

• 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

pokazują pewne szczegóły i testy wydajności.

Problem PO jest ograniczony do konkretnej sytuacji rzutowania. Tytuł obejmuje znacznie więcej sytuacji.
Oto przegląd wszystkich istotnych sytuacji castingowych, o których obecnie mogę myśleć:

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
}