Pourquoi ne peut-itérateur méthodes, prendre le " ref " ou " out " paramètres?

J'ai essayé plus tôt aujourd'hui:

public interface IFoo
{
    IEnumerable<int> GetItems_A( ref int somethingElse );
    IEnumerable<int> GetItems_B( ref int somethingElse );
}


public class Bar : IFoo
{
    public IEnumerable<int> GetItems_A( ref int somethingElse )
    {
        //Ok...
    }

    public IEnumerable<int> GetItems_B( ref int somethingElse )
    {
        yield return 7; //CS1623: Iterators cannot have ref or out parameters            

    }
}

Quelle est la logique derrière cela?

InformationsquelleAutor Trap | 2009-06-15
  1. 49

    C# itérateurs sont des machines d'état à l'interne. Chaque fois que vous yield return quelque chose, l'endroit où vous l'avez laissé devrait être enregistré en même temps que l'état des variables locales de sorte que vous pouvez revenir et continuer à partir de là.

    De tenir cet état, compilateur C# crée une classe afin de conserver les variables locales et la place qu'elle doit continuer à partir. Il n'est pas possible d'avoir un ref ou out valeur d'un champ dans une classe. Par conséquent, si vous avez été autorisé à déclarer un paramètre comme ref ou out, il n'y aurait pas moyen de garder la photo complète de la fonction au moment où nous l'avions laissé.

    EDIT: Techniquement, pas toutes les méthodes qui retournent des IEnumerable<T> sont considérés comme des itérateurs. Seulement ceux qui utilisent yield de produire directement une séquence sont considérés comme des itérateurs. Par conséquent, alors que le fractionnement de l'itérateur en deux méthodes est une belle solution de contournement commune, il n'est pas en contradiction avec ce que je viens de dire. L'extérieur de la méthode (qui n'utilise pas yield directement) est pas considéré comme un itérateur.

    • "Il n'est pas possible d'avoir une ref ou à la valeur d'un champ d'une classe." --Le compilateur pourrait facilement mettre en œuvre des paramètres de ref pour les itérateurs par l'attribution d'un seul élément de tableau en l'appelant, en mettant l'argument, et du passage du tableau à l'itérateur, et d'avoir l'itérateur fonctionner sur tableau[0]. Ce serait une très petite quantité de travail de la part du compilateur par rapport à la transformation de l'itérateur dans une machine à états.
    • Ce serait vrai si le compilateur contrôlé chaque morceau de code qui a couru. Malheureusement, ce plan aurait besoin d'un autre API signature doit être généré dans le fichier binaire--c'est à dire des personnes du monde extérieur en passant "ref" variables ne seraient pas en mesure de les voir en train de changer.
    • Euh, des personnes du monde extérieur ne peuvent pas passer dans les paramètres de ref à tous ... on ne peut. Donc, il serait pas mal de préciser qu'ref T paramètres pour les itérateurs sont représentés en tant que T[]. En tout cas, à l'aide d'un tableau ou d'une instance de classe comme une boîte est un moyen simple de contourner la limitation ... plus simple que les autres solutions proposées ici.
    • ils seront, si vous le permettez ref T, qui est le point de l'ensemble.
    • Euh, si C# génère une signature avec T[], qui n'est pas à l'extérieur que les appelants invoquent avec les ref T, tout comme ils ne peuvent pas maintenant. Il m'amuse toujours quand les gens parlent de "le point" quand, qui ignore totalement ce que l'autre personne dit. Je n'ai aucun intérêt à poursuivre la discussion quand je rencontre ... sur et en dehors.
    InformationsquelleAutor Mehrdad Afshari
  2. 18

    Si vous souhaitez retourner un itérateur et un int à partir de votre méthode, une solution de contournement est: est-ce

    public class Bar : IFoo
{
    public IEnumerable<int> GetItems( ref int somethingElse )
    {
        somethingElse = 42;
        return GetItemsCore();
    }

    private IEnumerable<int> GetItemsCore();
    {
        yield return 7;
    }
}

    Vous devriez noter que rien dans le code à l'intérieur d'une méthode d'itérateur (c'est à dire essentiellement une méthode qui contient yield return ou yield break) est exécutée jusqu'à ce que le MoveNext() méthode dans l'Énumérateur est appelé. Donc, si vous avez été en mesure d'utiliser out ou ref dans votre méthode d'itérateur, vous obtenez le comportement étonnant comme ceci:

    //This will not compile:
public IEnumerable<int> GetItems( ref int somethingElse )
{
    somethingElse = 42;
    yield return 7;
}

//...
int somethingElse = 0;
IEnumerable<int> items = GetItems( ref somethingElse );
//at this point somethingElse would still be 0
items.GetEnumerator().MoveNext();
//but now the assignment would be executed and somethingElse would be 42

    C'est un piège classique, une question est: est-ce

    public IEnumerable<int> GetItems( object mayNotBeNull ){
  if( mayNotBeNull == null )
    throw new NullPointerException();
  yield return 7;
}

//...
IEnumerable<int> items = GetItems( null ); //<- This does not throw
items.GetEnumerators().MoveNext();                    //<- But this does

    Donc un bon modèle est de séparer itérateur méthodes en deux parties: une pour l'exécuter immédiatement et l'autre qui contient le code qui doit être paresseusement exécuté.

    public IEnumerable<int> GetItems( object mayNotBeNull ){
  if( mayNotBeNull == null )
    throw new NullPointerException();
  //other quick checks
  return GetItemsCore( mayNotBeNull );
}

private IEnumerable<int> GetItemsCore( object mayNotBeNull ){
  SlowRunningMethod();
  CallToDatabase();
  //etc
  yield return 7;
}    
//...
IEnumerable<int> items = GetItems( null ); //<- Now this will throw

    EDIT:
    Si vous voulez vraiment le comportement en mouvement où l'itérateur serait de modifier la ref-paramètre, vous pourriez faire quelque chose comme ceci:

    public static IEnumerable<int> GetItems( Action<int> setter, Func<int> getter )
{
    setter(42);
    yield return 7;
}

//...

int local = 0;
IEnumerable<int> items = GetItems((x)=>{local = x;}, ()=>local);
Console.WriteLine(local); //0
items.GetEnumerator().MoveNext();
Console.WriteLine(local); //42
    • Re: le modifier avec un getter/setter lambdas, c'est une façon de simuler des pointeurs vers des types de valeur (bien que sans adresse de la manipulation, bien sûr), plus de détails ici: incrediblejourneysintotheknown.blogspot.com/2008/05/...
    • Très intéressante.
    • Plus simple que de passer un getter et setter est de mettre le "ref" paramètre dans une boîte-une instance de classe si vous avez plusieurs "ref" paramètres", ou tout simplement un seul élément de tableau, si vous avez juste une.
    InformationsquelleAutor Rasmus Faber
  3. 5

    À un highish niveau, Une référence de variable peut point à de nombreux endroits, y compris à des types de valeur sur la pile. L'heure à laquelle l'itérateur est d'abord créé par l'appel de la méthode de l'itérateur et quand la ref variable serait attribué deux époques très différentes. Il n'est pas possible de garantir que la variable qui à l'origine a été adoptée par la référence est toujours là quand l'itérateur exécute. Par conséquent, il n'est pas permis (ou vérifiable)

    InformationsquelleAutor JaredPar
  4. 4

    D'autres ont expliqué pourquoi votre itérateur peut pas avoir un paramètre de référence. Voici une alternative simple:

    public interface IFoo
{
    IEnumerable<int> GetItems( int[] box );
    ...
}

public class Bar : IFoo
{
    public IEnumerable<int> GetItems( int[] box )
    {
        int value = box[0];
        //use and change value and yield to your heart's content
        box[0] = value;
    }
}

    Si vous avez plusieurs articles à passer dans et hors, de définir une classe pour les tenir.

    InformationsquelleAutor Jim Balter
  5. 1

    J'ai contourné ce problème en utilisant des fonctions, lorsque la valeur que j'ai besoin de retour est dérivé de la itéré éléments:

    //One of the problems with Enumerable.Count() is
//that it is a 'terminator', meaning that it will
//execute the expression it is given, and discard
//the resulting sequence. To count the number of
//items in a sequence without discarding it, we 
//can use this variant that takes an Action<int>
//(or Action<long>), invokes it and passes it the
//number of items that were yielded.
//
//Example: This example allows us to find out
//         how many items were in the original
//         source sequence 'items', as well as
//         the number of items consumed by the
//         call to Sum(), without causing any 
//         LINQ expressions involved to execute
//         multiple times.
//
//  int start = 0;    //the number of items from the original source
//  int finished = 0; //the number of items in the resulting sequence
//
//  IEnumerable<KeyValuePair<string, double>> items = //assumed to be an iterator
//
//  var result = items.Count( i => start = i )
//                  .Where( p => p.Key = "Banana" )
//                     .Select( p => p.Value )
//                        .Count( i => finished = i )
//                           .Sum();
//
//  //by getting the count of items operated 
//  //on by Sum(), we can calculate an average:
//
//  double average = result /(double) finished; 
//
//  Console.WriteLine( "started with {0} items", start );
//  Console.WriteLine( "finished with {0} items", finished );
//

public static IEnumerable<T> Count<T>( 
    this IEnumerable<T> source, 
    Action<int> receiver )
{
  int i = 0;
  foreach( T item in source )
  {
    yield return item;
    ++i ;
  }
  receiver( i );
}

public static IEnumerable<T> Count<T>( 
    this IEnumerable<T> source, 
    Action<long> receiver )
{
  long i = 0;
  foreach( T item in source )
  {
    yield return item;
    ++i ;
  }
  receiver( i );
}
    InformationsquelleAutor