Quelqu'un connaitrait-il un moyen simple de récupérer le contenu d'un fichier CSV dans une structure de données (Tableau, table de hashage, liste chainée).
Cela m'éviterait de le re-coder (bien que ça ne doit pas être compliqué).

Même question pour le contenu d'un fichier .ini

En Perl il est très simple de le faire, alors s'il existe une ruse en Csharp...

Merci.

Ça va dépendre ce que contient ton csv mais je ferais une bête classe pour les données d'une ligne et une liste générique du type de ta classe pour stocker le tout.

Un truc du genre :

public class CsvLine
{
    private int _toto;
    public int Toto
    {
        get { return _toto; }
        set { _toto = value; }
    }

    public CsvLine(int toto)
	{
        _toto = toto;
	}
}

Puis :

edit : un petit bug dans la balise code qui n'affiche pas les plus grands/petits ni leur contenu. Cliques sur citer pour voir le vrai code de la ligne ci-dessous.

List<CsvLine> csvParsed = new List<CsvLine>();

Et après tu parses ton csv dans une boucle :

while (!file.EndOfStream)
{
    string line = file.ReadLine();
    char[] splitter = { ';' };
    string[] values = line.Split(splitter);

    csvParsed.Add(new CsvLine(values[0]));
}

Tu pourrais même encapsuler la liste dans une autre classe (CsvFile par exemple) et déporter la lecture du csv dans son constructeur.

Je suis de loin pas un expert en c# mais c'est facile à mettre en place et ça marche.

Dernière modification le 04/01/08 à 00:56 par Def

Merci de ton aide, Def.
Ta solution semble simple et élégante.

Par contre, déclarer 'splitter' dans la boucle, le compilateur ne va pas allouer la mémoire et affecter la valeur ';' à chaque itération ?
(je ne fais pas du C# depuis longtemps alors je ne sais pas comment se comporte le compilo).

La logique voudrait qu'à chaque itération de la boucle la mémoire soit à nouveau allouée. Ce serait plus élégant de la déclarer à l'extérieur effectivement. Elle est censé entre supprimé à la fin de chaque itération donc niveau mémoire ça ne change pas mais ça reste une instruction inutile.
Je t'avoue j'ai un peu taper ça en vitesse, je sais même pas si ça compile :)

Même réflexion pour les 2 autres variables si on veut être tatillon elles n'ont besoin de n'être déclarée qu'une fois pour toute la boucle même si elles sont elles assignées à chaque itération. Enfin si le garbage collector fait bien son boulot ça ne devrait pas faire de différence.

Def a écrit
La logique voudrait qu'à chaque itération de la boucle la mémoire soit à nouveau allouée. Ce serait plus élégant de la déclarer à l'extérieur effectivement. Elle est censé entre supprimé à la fin de chaque itération donc niveau mémoire ça ne change pas mais ça reste une instruction inutile.
Je t'avoue j'ai un peu taper ça en vitesse, je sais même pas si ça compile :)

Même réflexion pour les 2 autres variables si on veut être tatillon elles n'ont besoin de n'être déclarée qu'une fois pour toute la boucle même si elles sont elles assignées à chaque itération. Enfin si le garbage collector fait bien son boulot ça ne devrait pas faire de différence.

Disons que je me bats pour que les développeurs qui bossent pour moi fassent un peu attention à l'optimisation de leur code alors faire moi-même du code avec des allocations inutiles ça me gêne.

On a trop pris l'habitude, ayant des machines puissantes et de la mémoire, de ne pas y faire attention. Et on se retrouve avec des programmes très consommateurs.

Par exemple, les API que j'utilise pour générer des images au format UDF ont déjà du être codés avec les pieds : Lorsque je lance la création d'une image avec 3Go de données, le process utilise jusqu'à 600Mo de RAM et 600Mo de SWAP. Je trouve ça lamentable.