Pourquoi TypedReference se trouve-t-il dans les coulisses? C'est tellement rapide et sûr… presque magique!

Attention: cette question est un peu hérétique ... les programmeurs religieux respectant toujours les bonnes pratiques, ne la lisez pas. :)

Est-ce que quelqu'un sait pourquoi l'utilisation de TypedReference est si déconseillée (implicitement, par manque de documentation)?

J'en ai trouvé de bonnes utilisations, par exemple lors du passage de paramètres génériques via des fonctions qui ne devraient pas être génériques (lors de l'utilisation d'un objectpeut être excessif ou lent, si vous avez besoin d'un type valeur), lorsque vous avez besoin d'un pointeur opaque, ou pour quand vous avez besoin d'accéder rapidement à un élément d'un tableau, dont vous trouvez les spécifications au moment de l'exécution (en utilisant Array.InternalGetReference). Puisque le CLR n'autorise même pas une utilisation incorrecte de ce type, pourquoi est-il déconseillé? Cela ne semble pas dangereux ou quoi que ce soit ...

D'autres utilisations que j'ai trouvées pour TypedReference:

"Spécialisation" des génériques en C # (c'est du type sécurisé):

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

Écrire du code qui fonctionne avec des pointeurs génériques (c'est très dangereux en cas d'utilisation abusive, mais rapide et sûr s'il est utilisé correctement):

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

Ecrire une version méthode de l' sizeofinstruction, qui peut être parfois utile:

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

Ecriture d'une méthode qui passe un paramètre "state" qui veut éviter la boxe:

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*/ }
}

Alors pourquoi des utilisations comme celle-ci sont-elles «découragées» (faute de documentation)? Des raisons de sécurité particulières? Cela semble parfaitement sûr et vérifiable s'il n'est pas mélangé avec des pointeurs (qui ne sont pas sûrs ou vérifiables de toute façon) ...

Mettre à jour:

Exemple de code pour montrer que, en effet, TypedReferencepeut être deux fois plus rapide (ou plus):

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

(Edit: j'ai édité le benchmark ci-dessus, puisque la dernière version du post utilisait une version de débogage du code [j'ai oublié de le changer en release], et je n'ai mis aucune pression sur le GC. Cette version est un peu plus réaliste, et sur mon système, c'est plus de trois fois plus rapide avec TypedReferenceen moyenne.)

Réponse courte: portabilité .

Bien que __arglist, __makerefet __refvaluesont des extensions de langage et sont en situation irrégulière dans le langage C # Spécification, les constructions utilisées pour les mettre en œuvre sous le capot ( varargconvention d' appel, TypedReferencetype arglist, refanytype, mkanyrefet refanyvalinstructions) sont parfaitement documentées dans la spécification CLI (ECMA-335) en la bibliothèque Vararg .

Le fait d'être défini dans la bibliothèque Vararg montre clairement qu'ils sont principalement destinés à prendre en charge les listes d'arguments de longueur variable et pas grand-chose d'autre. Les listes d'arguments variables ont peu d'utilité dans les plates-formes qui n'ont pas besoin de s'interfacer avec du code C externe utilisant des varargs. Pour cette raison, la bibliothèque Varargs ne fait partie d'aucun profil CLI. Les implémentations CLI légitimes peuvent choisir de ne pas prendre en charge la bibliothèque Varargs car elle n'est pas incluse dans le profil du noyau CLI:

4.1.6 Vararg

L' ensemble de fonctionnalités vararg prend en charge les listes d'arguments de longueur variable et les pointeurs typés à l'exécution.

En cas d'omission: toute tentative de référencer une méthode avec la varargconvention d'appel ou les codages de signature associés aux méthodes vararg (voir Partition II) doit lever l' System.NotImplementedExceptionexception. Les méthodes utilisant les instructions du CIL arglist, refanytype, mkrefanyet refanyvaljetterons l' System.NotImplementedExceptionexception. Le moment précis de l'exception n'est pas spécifié. Le type System.TypedReferencen'a pas besoin d'être défini.

Mise à jour (réponse au GetValueDirectcommentaire):

FieldInfo.GetValueDirectne FieldInfo.SetValueDirectfont pas partie de la bibliothèque de classes de base. Notez qu'il existe une différence entre la bibliothèque de classes .NET Framework et la bibliothèque de classes de base. BCL est la seule chose requise pour une implémentation conforme de la CLI / C # et est documentée dans ECMA TR / 84 . (En fait, FieldInfolui-même fait partie de la bibliothèque Reflection et n'est pas non plus inclus dans le profil du noyau CLI).

Dès que vous utilisez une méthode en dehors de BCL, vous renoncez un peu à la portabilité (et cela devient de plus en plus important avec l'avènement des implémentations CLI non.NET comme Silverlight et MonoTouch). Même si une implémentation voulait augmenter la compatibilité avec la bibliothèque de classes Microsoft .NET Framework, elle pourrait simplement fournir GetValueDirectet SetValueDirectprendre un TypedReferencesans faire le TypedReferencespécialement géré par le runtime (en gros, ce qui les rend équivalents à leurs objecthomologues sans avantage en termes de performances).

S'ils l'avaient documenté en C #, cela aurait eu au moins quelques implications:

1. Comme toute fonctionnalité, elle peut devenir un obstacle à de nouvelles fonctionnalités, d'autant plus que celle-ci ne rentre pas vraiment dans la conception de C # et nécessite des extensions de syntaxe étranges et une remise spéciale d'un type par le runtime.
2. Toutes les implémentations de C # doivent en quelque sorte implémenter cette fonctionnalité et ce n'est pas nécessairement trivial / possible pour les implémentations C # qui ne s'exécutent pas du tout au-dessus d'une CLI ou ne s'exécutent pas sur une CLI sans Varargs.

Eh bien, je ne suis pas Eric Lippert, donc je ne peux pas parler directement des motivations de Microsoft, mais si je devais oser une supposition, je dirais que TypedReferenceet al. ne sont pas bien documentés car, franchement, vous n'en avez pas besoin.

Chaque utilisation que vous avez mentionnée pour ces fonctionnalités peut être accomplie sans elles, bien que dans certains cas, les performances soient pénalisées. Mais C # (et .NET en général) n'est pas conçu pour être un langage hautes performances. (Je suppose que "plus rapide que Java" était l'objectif de performances.)

Cela ne veut pas dire que certaines considérations de performances n'ont pas été prises en compte. En effet, des fonctionnalités telles que les pointeurs stackallocet certaines fonctions de framework optimisées existent en grande partie pour améliorer les performances dans certaines situations.

Les génériques, qui, je dirais, ont le principal avantage de la sécurité des types, améliorent également les performances de la même manière TypedReferencequ'en évitant la boxe et le déballage. En fait, je me demandais pourquoi vous préféreriez ceci:

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

pour ça:

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

Les compromis, comme je les vois, sont que le premier nécessite moins de JIT (et, il s'ensuit, moins de mémoire), tandis que le second est plus familier et, je suppose, légèrement plus rapide (en évitant le déréférencement du pointeur).

J'appellerais TypedReferenceet les détails d'implémentation d'amis. Vous avez souligné certaines utilisations intéressantes pour eux, et je pense qu'ils valent la peine d'être explorés, mais la mise en garde habituelle de se fier aux détails d'implémentation s'applique - la prochaine version peut casser votre code.

Je ne peux pas comprendre si le titre de cette question est censé être sarcastique: il est établi depuis longtemps que TypedReferencec'est le cousin lent, gonflé et laid des `` vrais '' pointeurs gérés, ce dernier étant ce que nous obtenons avec C ++ / CLI interior_ptr<T> , ou même les paramètres par référence ( ref/ out) traditionnels en C # . En fait, il est assez difficile d' TypedReferenceatteindre les performances de base en utilisant simplement un entier pour réindexer à chaque fois le tableau CLR d'origine.

Les tristes détails sont là , mais heureusement, rien de tout cela n'a d'importance maintenant ...

Cette question est maintenant rendue sans objet par les nouveaux locaux de référence et les fonctionnalités de retour de référence en C # 7

Ces nouvelles fonctionnalités de langage fournissent une prise en charge de premier ordre en C # pour la déclaration, le partage et la manipulation de vrais CLR types de types de référence gérés dans des situations soigneusement prédéfinies.

Les restrictions d'utilisation ne sont pas plus strictes que ce qui était auparavant requis TypedReference(et les performances sautent littéralement du pire au meilleur ), donc je ne vois aucun cas d'utilisation imaginable en C # pour TypedReference. Par exemple, auparavant, il n'y avait aucun moyen de conserver un TypedReferencedans le GCtas, donc la même chose est vraie pour les pointeurs gérés supérieurs maintenant n'est pas un retrait.

Et évidemment, la disparition de TypedReference- ou sa dépréciation presque complète au moins - signifie également jeter __makerefà la poubelle.