C #: Gardez le paramètre ref de constructeur en classe

Ce n'est pas vraiment une bonne idée de ce que vous essayez de faire, j'exposerais l'objet modifié comme une propriété de la classe comme ci-dessous:

public class ClassContructorReference
{
    static void Main(string[] args)
    {
        object var = new object();
        MyClass myClass = new MyClass(var);
        StringBuilder mySb = myClass.Instance as StringBuilder;
        Console.WriteLine(mySb.ToString());
    }
}

public class MyClass
{
    public object Instance {get;set;}

    public MyClass(object var)
    {
        this.Instance = var;
        DoSomething();
    }

    private void DoSomething()
    {
        this.Instance = new StringBuilder("Hello");
    }
}

J'aimerais pouvoir avoir une référence à une variable dans une instance d'une classe, mais j'aimerais que la référence devienne une variable de classe, donc je n'ai pas besoin de l'envoyer autour de la classe comme paramètre < / p>

Vous devrez vivre avec déception alors. Le système de type CLR interdit explicitement le stockage de références aux variables en tant que membres des classes. Le CLR permet des références aux variables à être

• transmis à des méthodes comme des arguments correspondant à des paramètres formels ou à "ceci"
• stocké en tant que locaux
• renvoyé comme méthode valide de retour

  mais pas permet de stocker le stockage dans les tableaux, les champs, etc. Fondamentalement, tout ce qui va "sur le tas" ne peut pas tenir une réf.

  C # expose la première fonctionnalité: Refs aux variables comme paramètres de la méthode. Il n'expose pas les deux autres caractéristiques (bien que j'ai écrit une version expérimentale de C # qui fonctionne, et cela fonctionne assez bien.)

  Notez que c # ne vous permet pas d'utiliser des réfs dans des contextes, ce qui nécessiterait un stockage de tas du paramètre réf - comme un paramètre Réf, une variable extérieure fermée d'une Lambda, par exemple. Il y a quelques cas rares dans lesquels le compilateur autorise ce qui ressemble à un stockage à long terme de la réfe et utilise la sémantique de copie-copie-copie pour imiter la Ref, mais probablement préférable de ne pas y aller.

  Pourquoi le CLR a-t-il cette restriction? La bonne façon d'y penser est qu'il existe deux types de stockage: long terme et court terme, généralement appelé "tas" et "pile". Mais la forme de la structure de données n'est pas pertinente; Ce qui est pertinent est la durée de la vie. Une variable a un lieu de stockage; C'est ce qu'une variable est. Si vous pouviez conserver une référence vers une variable allouée à partir du stockage à court terme dans un stockage à long terme, le stockage à long terme conserve une référence à quelque chose qui est de toute la durée de vie plus courte, et donc peut se bloquer et mourir lorsqu'il accède à la variable Après sa mort.

  évidemment, il existe de nombreuses façons de résoudre ce problème. Par exemple, l'équipe CLR aurait pu choisir de le rendre illégal de prendre une réfer à un stockage à court terme et de permettre le stockage des références dans le stockage à long terme. Mais cela signifie alors que vous ne pouvez pas prendre des références aux variables ou paramètres locaux, que vous souhaitez mettre au stockage à court terme car leur vie est si courte.

  La manière dont l'équipe CLR a choisi réellement consistait à interdire le stockage à long terme de toute réf. Comme toute décision de conception, c'était le résultat de nombreux compromis contre des objectifs concurrents.