Étant donné que c # n'a pas d'avant, après, dernier, premier, etc. dans le cadre de son forach. Le défi consiste à imiter ce comportement aussi élégamment possible avec les critères suivants: P>
Si vous pouvez dépasser les critères ci-dessus, veuillez patienter! P>
Je posterai ma réponse ci-dessous, mais ce n'est pas élégant ni que c'est réalisable, alors j'aimerais voir ce que la communauté peut évoquer. p>
codé dur pour les boucles devient parfois ennuyeux = ( p>
7 Réponses :
mon code, pas élégant. Appel simple à celui-ci: P> string[] testCollection = {"1", "2", "3", "4", "5"};
forEachDelegate primaryFunction = delegate(object o)
{
Response.Write(o.ToString());
};
forEachDelegate first = delegate(object o)
{
Response.Write("first");
};
forEachDelegate odd = delegate(object o)
{
Response.Write("odd");
};
forEachDelegate after = delegate(object o)
{
Response.Write("after");
};
Randoms.forEach(testCollection, primaryFunction, null, first, null, odd, null, after, Randoms.forEachExeuction.Concurrent);
En soutenant toutes vos exigences en une méthode très flexible, vous vous retrouvez avec l'équivalent de codage d'un couteau suisse de l'armée.
Mieux vaut fournir toutes ces capacités en tant que composants distincts que vous pouvez composer à chaque situation. p>
LINQ fournit un excellent point de départ. Pensez à Pour exécuter une séquence d'actions commodément, vous avez besoin: p> Maintenant, le problème est simplement de fournir une manipulation de séquence (dont une grande partie est déjà sous Linq) pour vous permettre de mettre en place une liste d'actions en fonction de vos besoins, vous pouvez donc mettre < code> exécuter code> à la fin. p> p> foreach code> comme moyen de convertir une liste d'objets dans une liste d'actions. Prenez cela littéralement: une séquence de
action code> délégués ou
iEnumerable
LINQ ... P>
.skiwhile (prédicat) code> (gauche vague comme votre sens n'est pas clair) li>
- Avant:
.Treuvement (prédicat) code> (gauche vague comme votre sens n'est pas clair) LI>
- Dernier:
.Last () code> li>
- premier:
.First () code> li>
- impair:
.where ((x, i) => i% 2 == 1) code> li>
- Même:
.Où ((x, i) => i% 2 == 0) code> li>
ul>
Je sais que les optimisations préalables sont une chose délicate. Mais j'ai fait une petite référence, comparant 1000000 de matrice [0] avec Array.First (). Les résultats sont 2 ms vs 80ms
@Majestictra, qui va bien, à l'exception de la question ne parle pas spécifiquement de tableaux (qui ont une information spécifique, donc oui: ils sont très rapides), et dans les cas les plus sensibles, le "et maintenant quelque chose avec la valeur" vapory se noie sur la valeur " obtenir la valeur "
Je ne discute pas avec aucun de vos mots) ma seule intention était de dire "mais vous devriez également savoir que l'appelant x [0] et x.First () n'est pas une chose identique"
jon skeet a écrit Smartenumerable pour Cet objectif. Il est facilement étendu pour fournir La réponse de Marc Gravell est bonne parce que c'est simple, mais il sera moins performant pour les cas où vous voulez d'abord faire quelque chose sur tous les éléments impairs, puis sur tous les éléments même, car cela vous aurait itérale à deux fois. , alors que seulement une seule fois est strictement nécessaire. p>
Je suppose que vous pouvez écrire une fonction d'un élément à une énumération et regroupez tous les éléments de la valeur de dénombrement qu'ils correspondent. Ensuite, vous pouvez facilement gérer chaque groupe séparément. Mais je ne suis pas sûr de savoir comment cela fonctionnerait, car je ne suis pas sûr de ce que Linq regrouper spécifiquement et combien cela est différé. P> isodd code> et
iSeven code>. P>
Juste une part - pour ce scénario "Push Linq" pourrait s'adapter - il permet plusieurs piles de traitement distinctes (toujours à l'aide de la même syntaxe Linq), de sorte que vous pouvez avoir exactement b> mon deux où code > s (en fait, tous), mais seulement itérer les données une fois.
Ah oui, un modèle de poussée serait certainement la meilleure solution pour des cas comme ça.
foreach(var item in collection.ToNavigable()) { if (item.IsFirst) { ... } if (item.IsLast) { ... } if (item.IsEven) { ... } if (item.IsOdd) { ... } Console.WriteLine(item.Value); }
Il devrait bien sûr être générique afin que vous n'ayez pas à jeter les valeurs. Vous pouvez utiliser le délégué d'action dans le cadre de la FRAMWork au lieu de déclarer votre propre.
ForEach<string>.Loop(testCollection, (s) => Console.WriteLine(s), null, (s) => Console.WriteLine("first"), null, (s) => Console.WriteLine("odd"), null, (s) => Console.WriteLine("after"), ForEachExecuction.Concurrent );
for (;;) {} Seriously. *P.S.: Conditions like Odd and After rely on strict and meaningful order, which makes foreach wrong in both meaning and syntax. One needs to know when to stop following fashion. Notice how suggested LINQ .SkipWhile(predicate) differs semantically from After(index) *
Comment? foreach code> exécute la déclaration pour chaque élément i> dans la collection, dans l'ordre exact qu'ils apparaissent dans la collection. Il a l'idée d'une séquence ordonnée intégrée à elle.
La commande est comme un détail de mise en œuvre pour foreach i>. Vous pouvez changer de type de collecte (à quelque chose sans ordre garanti) sans changer foreach i> Syntaxe. Le résultat compilera, mais ne fonctionnera pas si vous le souhaitez si vous comptez sur des indices d'éléments (impair) dans la clause foreach i>.
@IMA: commande n'est pas i> un détail de mise en œuvre, foreach code> itère via la séquence dans l'ordre i>. Si la séquence itératée a une ordonnance significative est une question distincte.
Luke, vous avez pointé sur le problème, mais vous ne pensez pas que c'est pertinent - mais cela est souvent. foreach i> iratera par séquence dans l'ordre, aucune question à ce sujet. Et vous pouvez mettre en œuvre, disons, evaire i> événement dans foreach i>. Et cela fonctionnera sans compiler des avertissements, même si l'ordre de collection particulière est indéfini - que le problème dont je parle, une recette pour quelques bogues de guichet méchante.
Sémantiquement, les conditions de forach ne doivent dépendre que des propriétés des articles de collecte, pas sur leurs indices. Si vous souhaitez utiliser des produits partout (cela peut être une bonne pratique), il est préférable de concevoir votre programme de manière à ce que vous n'ayez pas besoin de compter sur des indices nulle part. L'approche triviale consiste à inclure des indices importants dans les propriétés des objets d'élément.
quelquewebguy.wordpress.com/2009/09/02/build -A-Smarter-Loop
Y a-t-il une langue qui fournit cette fonction? Ce n'est pas une critique, je me demande simplement de ce que cela ressemblerait dans une autre langue.