Discussion :

[replica]

Bonjour,

Lorsque j'utilise le foreach avec des tableaux, j'ai parfois besoin de faire ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
int i = 0;
foreach (Element e in Elements)
{
	Tab[i] = Element.Data;
	i++;
}

A l'intérieur d'une boucle foreach, existe t'il un mot clé représentant ma variable d'incrémentation i ?

Merci

[Guulh]

Non, il n'y a pas de variable d'incrémentation dans un foreach.

Après, es-tu obligé d'utiliser un tableau ? Si ce sont des List<T> tu peux écrire ton code ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

List<int> Tab = Elements.ConvertAll<int>(delegate (Element e) { return e.Data; });

Et Si tu utilises C# 3, tu as Linq à ta disposition, qui permet de l'écrire de façon encore plus concise (mais là, n'ayant pas beaucoup utilisé Linq, je laisse plus compétent que moi te le montrer )

[laedit]

Pourquoi ne pas utiliser une boucle for tout simplement ?

[replica]

Je suis d'accords avec toi dans ce cas la boucle for est plus intéressante. Mais s'il y avait eu une variable d'incrémentation disponible le foreach était mieux.

@Guulh : Je suis obligé d'utiliser des tableaux mais ta solution est bien plus élégante.

Merci beaucoup pour vos réponse.

[tomlev]

Juste pour info, des solutions possibles avec Linq :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

var Tab = Elements.Select(e => e.Data).ToList();

ou encore :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
var Tab = (from e in Elements
           select e.Data).ToList();

(exactement équivalent à la version précédente, mais avec la syntaxe de requête)

Et la solution de Guulh avec la syntaxe C# 3 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

var Tab = Elements.ConvertAll(e => e.Data);

(pas besoin de spécifier le paramètre de type générique, grâce à l'inférence de type)

[Guulh]

Juste pour info, des solutions possibles avec Linq

J'ajoute que la List<T> a une méthode ToArray (qui renvoie un T[]), et qu'il existe aussi une méthode d'extension du même nom.

Mais bon, les tableaux, il y a TRES peu de raisons de continuer à s'en servir. Comme l'a dit un monsieur très intelligent : "In almost every case, there is a better tool to use than an array."
http://blogs.msdn.com/ericlippert/ar...t-harmful.aspx

[olibara]

Mais bon, les tableaux, il y a TRES peu de raisons de continuer à s'en servir

Voici un exemple ou a mon avis (meme si je suis friand des listes, un tableau est plus mieux)

Je dispose d'une collection de +/- 40.000 elements d'une classe
Chaque element de cette classe PEUT avoir un tableau de maximum 6 KeyValuePair String,int

Il me semble que 40.000 Array seront moins couteux que 40000 Listes ?

[Guulh]

Il me semble que 40.000 Array seront moins couteux que 40000 Listes ?

Coûteux en quoi ? En mémoire ? Pas sûr.
Déjà, je suis pas persuadé que la différence soit très sensible si on ne manipule que des dizaines de milliers d'éléments (pour des millions ou dizaines de millions, peut être).
Et si la plupart de tes arrays ne contiennent que un ou deux éléments, ça fait pas mal de place de perdue, non ? Alors que si tu crées des listes, voire même que tu forces leur capacité à 2 ou 4, ça prendra moins de place.

[tomlev]

Il me semble que 40.000 Array seront moins couteux que 40000 Listes ?

Pour des petits tableaux, effectivement c'est moins couteux. Pour des grands tableaux, la différence est minime : une liste, c'est finalement juste un wrapper autour d'un tableau, il y a juste quelques champs en plus. Par exemple si tu regardes la classe List<T> avec Reflector :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
    // Fields
    private const int _defaultCapacity = 4; // statique, donc on s'en fout
    private static T[] _emptyArray;  // statique, donc on s'en fout
    private T[] _items; // le tableau qui contient les données
    private int _size; // le nombre d'éléments
    [NonSerialized]
    private object _syncRoot; // pour la synchronisation en multithread
    private int _version; // je sais pas trop pourquoi

Donc au final, tu as juste 3 champs en plus par rapport à un simple tableau. Par contre, le tableau _items est généralement plus grand que nécessaire (pour ne pas avoir besoin de l'agrandir à chaque fois qu'on ajoute un élément). Donc pour un grand nombre d'éléments, le coût des champs supplémentaires et de l'espace inutilisé du tableau n'est pas très important par rapport à l'espace occupé par les éléments eux-mêmes

[olibara]

Merci Tomlev le spécialiste Reflector

Ce que tu montre confirme asser bien que mon option dans le contexte donné est bonne.

Par contre je découvre que la List c'est un simple Wrapper sur un tableau
(tableau de reference certainement)
J'avais cru (mais c'etait idiot) qu'il s'agissait de liste chainées

[tomlev]

J'avais cru (mais c'etait idiot) qu'il s'agissait de liste chainées

Ca existe aussi
http://msdn.microsoft.com/en-us/library/he2s3bh7.aspx