Discussion :

[Lorenzo77]

salut,

est ce qu'il existe une manière de transformer un string[] en List<string> sans utiliser une boucle sur l'intégralité des éléments ?
ca doit être faisable vu que les 2 sont très proche !?

j'ai essayé contenu.Cast<List<string>>() mais ca plante :

Impossible de convertir implicitement le type 'System.Collections.Generic.IEnumerable<System.Collections.Generic.List<string>>' en 'System.Collections.Generic.List<string>'. Une conversion explicite existe (un cast est-il manquant*?)

une idée ?

merci

[gdkenny]

Salut.

ce code marche à partir du framework 3.0:

Code :

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

1
2
 
string[] t; t.ToList();

Les méthodes d'extension, c'est bien. CQFD

[ArianeV]

tiens c'est cool ca !

Et c'est vraiment en O(1) comme opération ? Aucun parcours du tableau ?

[gdkenny]

Si, il doit y avoir parcours, vu que ToList() est une méthode d'extension de l'interface IEnumerable<T>.

Il y a même un p'tit coup d'inférence de type par dessus. Je sais pas ce que ca donne niveau performances, en tout cas c'est bien pratique

[smyley]

Et c'est vraiment en O(1) comme opération ? Aucun parcours du tableau ?

Ah mon avis c'est plus un O(n) car il faut après tout copier les valeurs du tableau vers la liste (qui n'est pas un tableau) ou en tout cas dupliquer le tableau. Mais de toute façon vu que c'est au maximum linéaire ça doit pas être très pénalisant.

[StormimOn]

est ce qu'il existe une manière de transformer un string[] en List<string> sans utiliser une boucle sur l'intégralité des éléments ? ca doit être faisable vu que les 2 sont très proche !?

Non ce n'est pas faisable. Ce n'est pas parce que les notions sont "proches" que les conversions sont pour autant possibles.

Boucler est inutile dans le cas présent puisque le framework est capable de le faire lui même. La plupart des classes de collections acceptent un IEnumerable via le constructeur ou bien possèdent une méthode AddRange pour ajouter plusieurs éléments.

Code :

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

1
2
3
4
5
6
string[] tabString = { "chaine1", "chaine2", "chaine3" };
// Méthode 1
List<string> listString1 = new List<string>(tabString);
// Méthode 2
List<string> listString2 = new List<string>();
listString2.AddRange(tabString);

[ArianeV]

Hmmm

Donc finalement ce n'est pas possible de passer du tableau à la liste sans faire de parcours de tous les éléments (vu que c'est le framework qui le fait)...

C'est bien dommage...

[Pol63]

le framework le fait mais il doit faire une boucle (ou mieux en optimisé vu que niveau mémoire ca doit se suivre)

m'enfin ce genre de choses est ultra rapide
.net pour tout ce qui est non graphique ca turbine !

[Lorenzo77]

merci a vous

[Guulh]

Il me semble avoir vu dans ce forum que le constructeur de List qui prend un IEnumerable en entrée vérifie si le paramètre est une icollection, auquel cas il en extrait la taille, de façon à allouer dès le début une capacité suffisante. Un petit coup de Reflector nous en dirait plus

[gdkenny]

Il me semble avoir vu dans ce forum que le constructeur de List qui prend un IEnumerable en entrée vérifie si le paramètre est une icollection, auquel cas il en extrait la taille, de façon à allouer dès le début une capacité suffisante.

Je comprend pas l'intérêt la: une liste par définition alloue dans le tas des emplacements non consécutifs;c'est dynamique quoi.
A moins que ce soit plus rapide de (1)allouer l'espace, (2)populer les données, dans ce cas de 'cast'?

[ArianeV]

Non

En .NET List est l'équivalent du Vector en C++ : c'est un tableau dynamique.

En gros, sa taille augmente mais les emplacements sont contigus : l'intérêt c'est que tu ne passes pas ton temps à allouer de l'espace.

En plus, quand tu accèdes à l'élément numéro 150 de ta liste, il sait directement où il se trouve. si tu étais dans une liste chainée, il devrait parcourir les 149 premiers pour savoir où se trouve le 150ème, ce qui est dramatique au niveau perf

Ceci étant, tous les éléments ne sont pas contigus je crois. Techniquement, c'est plutot une liste chainée de tableaux. Du coup le temps est quasiment constant, et tu peux le faire grossir à la volée sans que ca ne te coute rien.

[gdkenny]

OK.

Pourquoi il l'on pas appelé Vector leur liste alors?
Et sinon, il y a une vraie liste chaînée en .NET?

[smyley]

LinkedList<T>

[gdkenny]

Merci

[Guulh]

Ceci étant, tous les éléments ne sont pas contigus je crois. Techniquement, c'est plutot une liste chainée de tableaux. Du coup le temps est quasiment constant, et tu peux le faire grossir à la volée sans que ca ne te coute rien.

On ne dirait pas. La msdn dit ( http://msdn.microsoft.com/fr-fr/libr...d1(VS.80).aspx ):

Si Count est inférieur à Capacity, cette méthode est une opération O(1). Si la capacité doit être augmentée pour intégrer le nouvel élément, cette méthode devient une opération O(n), où n est égal à Count.

Ce qui laisse croire que si la capacité est insuffisante, on recopie le buffer existant dans un buffer plus grand.

Et pourquoi ça s'appelle pas vector ? Parce que c'est pas un vecteur, et que la STL n'a pas des conventions de nommage universelles