Dlaczego TypedReference jest za kulisami? To takie szybkie i bezpieczne… prawie magiczne!

Ostrzeżenie: To pytanie jest trochę heretyckie ... religijni programiści zawsze przestrzegają dobrych praktyk, proszę go nie czytać. :)

Czy ktoś wie, dlaczego korzystanie z TypedReference jest tak odradzane (domyślnie z powodu braku dokumentacji)?

Znalazłem dla niego świetne zastosowania, na przykład podczas przekazywania parametrów ogólnych przez funkcje, które nie powinny być ogólne (gdy użycie objectmoże być przesadne lub wolne, jeśli potrzebujesz typu wartości), gdy potrzebujesz nieprzezroczystego wskaźnika lub gdy potrzebujesz szybko uzyskać dostęp do elementu tablicy, którego specyfikacje znajdziesz w czasie wykonywania (używając Array.InternalGetReference). Skoro CLR nie pozwala nawet na nieprawidłowe użycie tego typu, dlaczego jest odradzane? To nie wydaje się być niebezpieczne ani nic ...

Inne zastosowania, które znalazłem TypedReference:

„Specjalizacja” typów ogólnych w C # (to jest bezpieczne dla typów):

static void foo<T>(ref T value)
{
    //This is the ONLY way to treat value as int, without boxing/unboxing objects
    if (value is int)
    { __refvalue(__makeref(value), int) = 1; }
    else { value = default(T); }
}

Pisanie kodu, który działa z ogólnymi wskaźnikami (jest to bardzo niebezpieczne, jeśli zostanie niewłaściwie użyte, ale szybkie i bezpieczne, jeśli zostanie użyte poprawnie):

//This bypasses the restriction that you can't have a pointer to T,
//letting you write very high-performance generic code.
//It's dangerous if you don't know what you're doing, but very worth if you do.
static T Read<T>(IntPtr address)
{
    var obj = default(T);
    var tr = __makeref(obj);

    //This is equivalent to shooting yourself in the foot
    //but it's the only high-perf solution in some cases
    //it sets the first field of the TypedReference (which is a pointer)
    //to the address you give it, then it dereferences the value.
    //Better be 10000% sure that your type T is unmanaged/blittable...
    unsafe { *(IntPtr*)(&tr) = address; }

    return __refvalue(tr, T);
}

Pisanie wersji instrukcji metodysizeof , która może być czasami przydatna:

static class ArrayOfTwoElements<T> { static readonly Value = new T[2]; }

static uint SizeOf<T>()
{
    unsafe 
    {
        TypedReference
            elem1 = __makeref(ArrayOfTwoElements<T>.Value[0] ),
            elem2 = __makeref(ArrayOfTwoElements<T>.Value[1] );
        unsafe
        { return (uint)((byte*)*(IntPtr*)(&elem2) - (byte*)*(IntPtr*)(&elem1)); }
    }
}

Pisanie metody, która przekazuje parametr „stan”, który chce uniknąć pakowania:

static void call(Action<int, TypedReference> action, TypedReference state)
{
    //Note: I could've said "object" instead of "TypedReference",
    //but if I had, then the user would've had to box any value types
    try
    {
        action(0, state);
    }
    finally { /*Do any cleanup needed*/ }
}

Dlaczego więc takie zastosowania są „odradzane” (z powodu braku dokumentacji)? Jakieś szczególne względy bezpieczeństwa? Wydaje się całkowicie bezpieczne i sprawdzalne, jeśli nie jest pomieszane ze wskaźnikami (które i tak nie są bezpieczne ani weryfikowalne) ...

Aktualizacja:

Przykładowy kod, aby pokazać, że rzeczywiście TypedReferencemoże być dwukrotnie szybszy (lub więcej):

using System;
using System.Collections.Generic;
static class Program
{
    static void Set1<T>(T[] a, int i, int v)
    { __refvalue(__makeref(a[i]), int) = v; }

    static void Set2<T>(T[] a, int i, int v)
    { a[i] = (T)(object)v; }

    static void Main(string[] args)
    {
        var root = new List<object>();
        var rand = new Random();
        for (int i = 0; i < 1024; i++)
        { root.Add(new byte[rand.Next(1024 * 64)]); }
        //The above code is to put just a bit of pressure on the GC

        var arr = new int[5];
        int start;
        const int COUNT = 40000000;

        start = Environment.TickCount;
        for (int i = 0; i < COUNT; i++)
        { Set1(arr, 0, i); }
        Console.WriteLine("Using TypedReference:  {0} ticks",
                          Environment.TickCount - start);
        start = Environment.TickCount;
        for (int i = 0; i < COUNT; i++)
        { Set2(arr, 0, i); }
        Console.WriteLine("Using boxing/unboxing: {0} ticks",
                          Environment.TickCount - start);

        //Output Using TypedReference:  156 ticks
        //Output Using boxing/unboxing: 484 ticks
    }
}

(Edycja: edytowałem powyższy test porównawczy, ponieważ ostatnia wersja postu używała wersji kodu do debugowania [zapomniałem go zmienić do wydania] i nie naciskałem na GC. Ta wersja jest nieco bardziej realistyczna i w moim systemie jest TypedReferenceśrednio ponad trzy razy szybszy ).

Krótka odpowiedź: przenośność .

Chociaż __arglist, __makerefi __refvaluesą rozszerzeniami języka i nieudokumentowanych w C # Language Specification, konstrukty stosowane do ich wdrożenia pod maską ( varargnazywając konwencję, TypedReferencetyp, arglist, refanytype, mkanyref, i refanyvalinstrukcje) są doskonale udokumentowane w CLI Specification (ECMA-335) w biblioteka Vararg .

Zdefiniowanie w Bibliotece Vararg jasno pokazuje, że mają one przede wszystkim wspierać listy argumentów o zmiennej długości i niewiele więcej. Listy zmiennych argumentów mają niewielkie zastosowanie na platformach, które nie muszą łączyć się z zewnętrznym kodem C, który używa varargs. Z tego powodu biblioteka Varargs nie jest częścią żadnego profilu CLI. Legalne implementacje CLI mogą nie obsługiwać biblioteki Varargs, ponieważ nie jest ona uwzględniona w profilu jądra CLI:

4.1.6 Vararg

Zestaw funkcji vararg obsługuje listy argumentów o zmiennej długości i wskazówki wykonawcze wpisany.

Jeśli pominięto: Każda próba odniesienia do metody przy użyciu varargkonwencji wywoływania lub kodowania podpisu skojarzonego z metodami vararg (patrz Partycja II) spowoduje zgłoszenie System.NotImplementedExceptionwyjątku. Sposoby korzystania z instrukcji CIL arglist, refanytype, mkrefany, i refanyvalpowinna rzucić System.NotImplementedExceptionwyjątek. Dokładny czas wystąpienia wyjątku nie jest określony. Nie System.TypedReferencetrzeba określać typu.

Aktualizacja (odpowiedź na GetValueDirectkomentarz):

FieldInfo.GetValueDirectsą FieldInfo.SetValueDirectto nie część Base Class Library. Zauważ, że istnieje różnica między biblioteką klas .NET Framework a biblioteką klas podstawowych. BCL jest jedyną rzeczą wymaganą do zgodnej implementacji CLI / C # i jest udokumentowane w ECMA TR / 84 . (W rzeczywistości FieldInfojest częścią biblioteki Reflection i nie jest też uwzględniona w profilu jądra CLI).

Gdy tylko użyjesz metody poza BCL, rezygnujesz z nieco przenośności (a to staje się coraz ważniejsze wraz z pojawieniem się implementacji innych niż .NET CLI, takich jak Silverlight i MonoTouch). Nawet gdyby implementacja chciała zwiększyć kompatybilność z biblioteką klas Microsoft .NET Framework, mogłaby po prostu dostarczyć GetValueDirecti SetValueDirectwziąć plik TypedReferencebez tworzenia TypedReferencespecjalnie obsługiwanego przez środowisko wykonawcze (zasadniczo czyniąc je równoważnymi z ich objectodpowiednikami bez korzyści wydajnościowych).

Gdyby udokumentowali to w C #, miałoby to co najmniej kilka konsekwencji:

1. Jak każda funkcja, może stać się przeszkodą dla nowych funkcji, zwłaszcza, że ​​ta tak naprawdę nie pasuje do projektu C # i wymaga dziwnych rozszerzeń składni i specjalnego traktowania typu przez środowisko wykonawcze.
2. Wszystkie implementacje C # muszą w jakiś sposób zaimplementować tę funkcję i niekoniecznie jest to trywialne / możliwe dla implementacji C #, które w ogóle nie działają na CLI lub działają na CLI bez Varargs.

Cóż, nie jestem Ericem Lippertem, więc nie mogę bezpośrednio mówić o motywacjach Microsoftu, ale gdybym zaryzykował zgadywanie, powiedziałbym, że TypedReferencei in. nie są dobrze udokumentowane, ponieważ, szczerze mówiąc, nie potrzebujesz ich.

Każde użycie tych funkcji, o którym wspomniałeś, można wykonać bez nich, aczkolwiek w niektórych przypadkach ze spadkiem wydajności. Ale C # (i ogólnie .NET) nie jest zaprojektowany jako język o wysokiej wydajności. (Domyślam się, że celem wydajności było „szybsze niż Java”).

Nie oznacza to, że nie uwzględniono pewnych kwestii dotyczących wydajności. Rzeczywiście, takie funkcje, jak wskaźniki stackalloci pewne zoptymalizowane funkcje struktury istnieją głównie w celu zwiększenia wydajności w określonych sytuacjach.

Leki generyczne, które, jak powiedziałbym, mają główną zaletę w postaci bezpieczeństwa typów, również poprawiają wydajność, podobnie jak TypedReferencedzięki unikaniu pakowania i rozpakowywania. Właściwie zastanawiałem się, dlaczego wolisz to:

static void call(Action<int, TypedReference> action, TypedReference state){
    action(0, state);
}

do tego:

static void call<T>(Action<int, T> action, T state){
    action(0, state);
}

Jak widzę, kompromisy polegają na tym, że ten pierwszy wymaga mniej JIT (i, co za tym idzie, mniej pamięci), podczas gdy drugi jest bardziej znany i, jak zakładam, nieco szybszy (unikając dereferencji wskaźnika).

Zadzwoniłem TypedReferencei znajomi o szczegóły realizacji. Wskazałeś dla nich kilka zgrabnych zastosowań i myślę, że warto je zbadać, ale obowiązuje zwykłe zastrzeżenie polegające na poleganiu na szczegółach implementacji - następna wersja może złamać twój kod.

Nie mogę się dowiedzieć, czy tytuł tego pytania ma być sarkastyczny: od dawna ustalono, że TypedReferencejest powolnym, rozdętym, brzydkim kuzynem `` prawdziwych '' zarządzanych wskaźników, które otrzymujemy w C ++ / CLI interior_ptr<T> , lub nawet tradycyjne parametry przez odniesienie ( ref/ out) w C # . W rzeczywistości dość trudno jest osiągnąć TypedReferencenawet podstawową wydajność, używając tylko liczby całkowitej do ponownego indeksowania oryginalnej tablicy CLR za każdym razem.

Smutne szczegóły są tutaj , ale na szczęście nic z tego nie ma teraz znaczenia ...

To pytanie jest teraz rozwiązywane przez nowe lokalizacje referencyjne i funkcje zwracania referencji w C # 7

Te nowe funkcje językowe zapewniają widoczną, pierwszorzędną obsługę języka C # w celu deklarowania, udostępniania i manipulowania typami prawdziwie CLR zarządzanych typów referencyjnych w dokładnie określonych sytuacjach.

Ograniczenia użycia nie są bardziej rygorystyczne niż to, co było wcześniej wymagane TypedReference(a wydajność dosłownie przeskakuje od najgorszego do najlepszego ), więc nie widzę żadnego innego możliwego przypadku użycia w C # dla TypedReference. Na przykład wcześniej nie było sposobu, aby utrzymać się TypedReferencew GCstercie, więc to samo dotyczy lepszych wskaźników zarządzanych, teraz nie jest to kwestia na wynos.

I oczywiście upadek TypedReference- a przynajmniej jego prawie całkowite wycofanie się - oznacza również wyrzucenie __makerefna śmietnik.