Lecture CSV en C++, le faire � comme il faut �

Version imprimable

Voir 40 message(s) de cette discussion en une page

08/07/2015, 14h38
white_tentacle

Lecture CSV en C++, le faire � comme il faut �

Bonjour,

Je vous pr�sente un article qui, � partir d�un probl�me simple, pr�sente la m�thodologie et les techniques � mettre en �uvre pour arriver � une solution performante, r�utilisable.

http://julien-blanc.developpez.com/t...cture-csv-c++/

Bonne lecture
08/07/2015, 14h46
prgasp77

Bonjour,

c'est un tr�s bon sujet d'article ; la lecture d'un fichier CSV (un vrai, avec tous les pi�ges qu'il peut contenir) est parfois faite de mani�re bien bancale :mouarf:.
09/07/2015, 12h04
MichaelREMY

importer un fichier CSV en c++

tr�s bon article !

un BigUp! pour la partie qui traite de l'importance de la taille du fichier, qui va conditionner la m�thode de lecture. On ne le dira jamais assez traiter un fichier de 400Go sur une machine perso n'est pas pareil que de le faire sur un serveur virtualis� mutualis� ou de prod. Sans parler du probl�me de cache, de m�moire, du temp, de ressources par utilisateur.....

Une petite astuce personnel:
maintenant je traite le probl�me d'encodage manuellement avec un �diteur � part, car souvent, trop souvent on tombe sur des fichiers CSV multi-encodage qui ont �t� mal g�r�s par les exportateurs....
Oui alors avant l�entr�e dans la boucle, penser � une fonction juste pour tester l�int�gralit� du bon codage (et par la m�me occasion l�int�gralit� du fichier au cas o� il est d�fectueux)

Une petite am�lioration pour l'article: vous ne parlez pas de la source (disque dur, r�seau, nas, lien dropbox, lien cloud..etc) du fichier et de son impact, de son traitement en t�che de fond plut�t qu'en foreground.
09/07/2015, 12h31
LandReagan

Excellent, j'en avais justement besoin !
Merci beaucoup ! �a va m'�viter quelques heures d'arrachage de cheveux et quelques litres de caf�... :mrgreen:

Citation:

Envoy� par MichaelREMY

Une petite am�lioration pour l'article: vous ne parlez pas de la source (disque dur, r�seau, nas, lien dropbox, lien cloud..etc) du fichier et de son impact, de son traitement en t�che de fond plut�t qu'en foreground.

La partie VI en parle, ou du moins donne des �l�ments de r�ponse : la source des donn�es n'a pas d'impact (autre que les performances : on peut pas traiter les donn�es plus rapidement qu'elles arrivent).

Si tu veux faire tes traitements de mani�re asynchrone, rien ne change non plus
Code:

1 2 3 4 5 6 7 8 9 10 Threadpool pool; // ou autre CSVParser parser; parser.onField([](std::string const& f) { std::cout << f << std::endl; }); // traitement synchrone parser.onField([&](std::string const& f) { pool.enqueue([f]() { std::cout << f << std::endl; }); }); // traitement asynchrone std::vector<char> data; for(auto c: data) { parser.consume(c); }

Citation:
Envoy� par Iradrille
La partie VI en parle, ou du moins donne des �l�ments de r�ponse : la source des donn�es n'a pas d'impact (autre que les performances : on peut pas traiter les donn�es plus rapidement qu'elles arrivent).

Si tu veux faire tes traitements de mani�re asynchrone, rien ne change non plus
Code:

1 2 3 4 5 6 7 8 9 10 Threadpool pool; // ou autre CSVParser parser; parser.onField([](std::string const& f) { std::cout << f << std::endl; }); // traitement synchrone parser.onField([&](std::string const& f) { pool.enqueue([f]() { std::cout << f << std::endl; }); }); // traitement asynchrone std::vector<char> data; for(auto c: data) { parser.consume(c); }
oui oui, je voulais juste dire qu'avant d'importer le fichier, il faut s'assurer, ou plut�t estimer la longeur de la large pour ne pas monopoliser (ou plut�t ennuyer l'utilisateur devant l'�cran) et ainsi traiter le tout en background permettant ainsi d'afficher une chrono, une jauge. Comem fait maintenant Youtube pour l'import des vid�os. Rappelez-vous avant (dans les ann�es 2000) o� on attendez devant l'�cran que l'upload se finisse pour remplir le formulaire et ensuite faire autre chose.... C'es ce point l� que je voulais mettre en avant : estimer avant de travailler, m�me un traitement d'apparence simple...
c'est un tr�s bon article-tuto que vous avez �crit l�.

09/07/2015, 18h46
dragonjoker59

Citation:

Envoy� par MichaelREMY

oui oui, je voulais juste dire qu'avant d'importer le fichier, il faut s'assurer, ou plut�t estimer la longeur de la large pour ne pas monopoliser (ou plut�t ennuyer l'utilisateur devant l'�cran) et ainsi traiter le tout en background permettant ainsi d'afficher une chrono, une jauge...

Ce qui n'a strictement aucun rapport avec le parseur, mais avec la mani�re dont il est utilis�, donc compl�tement hors de propos.
09/07/2015, 20h36
white_tentacle

Citation:

Envoy� par dragonjoker59

Ce qui n'a strictement aucun rapport avec le parseur, mais avec la mani�re dont il est utilis�, donc compl�tement hors de propos.

En fait, oui et non. C�est pour �a que j�en ai parl� un peu, mais seulement un peu. Je me suis plac� du point du vue du concepteur de biblioth�que. � mon sens, c�est celui qu�on devrait toujours appliquer (une application, c�est une biblioth�que m�tier avec une interface par-dessus). Et dans cette optique-l�, ce qui est important, c�est surtout d�imposer le minimum de contraintes � son utilisateur. Devoir conna�tre � l�avance la taille des donn�es (ou au moins une approximation), par exemple, c�est une fonctionnalit� importante pour certaines application, mais c�est impossible pour d�autres (donn�es lues depuis un flux quelconque, type socket ou stdin). Donc ce qui est important, c�est :
* de ne rien imposer
* de fournir les moyens pour l�applicatif de mettre en �uvre son besoin.

Ici, la progression et l�information d�avancement de celle-ci se g�rera dans le handler, qui pourra � son tour notifier l�interface par un moyen quelconque � chaque avancement. Toutefois, la biblioth�que ne notifie o� elle en est du fichier qu�en cas d�erreur. Donc soit :
- on d�cide que cette information doit �tre fournie par la personne en charge de la lecture du fichier (d�un certain point de vue, c�est m�me tr�s discutable d�avoir int�gr� cette gestion de position courante directement dans notre parseur : c�est plut�t la commodit� qui l�a dict�e qu�autre chose). Lui se greffe pour �tre notifi� des fins d�enregistrement par le parseur, et notifie � son tour qui de droit avec les donn�es suppl�mentaires requises comme le %age d�avancement.
- on d�cide que cette information doit �tre disponible � tout moment, via des m�thodes publiques sur le parseur
- on d�cide que cette information doit transiter dans les callbacks

Ma pr�f�rence va � la premi�re solution (c�est d�ailleurs la seule qui ne n�cessite pas de modifier le code de l�article ;) ), mais la troisi�me peut se r�v�ler plus simple � mettre en �uvre si le lecteur et le consommateur final sont tr�s distincts.
09/07/2015, 21h01
EpiTouille

moi qui ai toujours fait un get_line et un split, je vais peut �tre regarder le tuto... :D
22/10/2015, 17h58
Invit�

Tr�s bon tuto, merci.

Je g�re plusieurs fichiers csv dans mon programme.
Et aucun d'entre eux n'est similaire.
Vous me simplifiez la vie.

Ou puis je trouver le fichier archive comme stipul� ?

Merci encore.
03/11/2015, 19h39
Paul_R

Bonjour,

Etant d�butant en C++ je cherche un moyen "g�n�rique" de lire des fichiers csv.

Cet article m'aide beaucoup dans la logique qui d�coule de la lecture du fichier csv. Par contre, tout comme fnallet94, je cherche le fichier archive stipul� plusieurs fois dans l'article sans pouvoir le trouver. Avez vous un lien ?

J'ai n�anmoins � partir des bouts de code r�ussit � reconstruire plus ou moins. A savoir que je ne compile pas avec le c++11 et que du coup je n'ai pas acc�s � "enum class", au wraper "function",...

Par contre je n'arrive � comprendre comment sont utilis�s (et cod�) les fonctions de rappels tel que field_handler(c).

Dans la classe csv_parser j'ai une m�thode call_field_handler(). Je ne vois pas comment li� la methode field_handler(c) de csv_data_handler � call_field_handler() de csv_parser...
05/11/2015, 13h57
white_tentacle

Bonjour,

J�ai mis � jour l�article avec le fichier manquant (sinon, il est ici). J�en ai profit� pour changer la licence. Du coup, il y a des exemples d�utilisation.

Pour � call_field_handler �, de m�moire, c�est juste un helper qui teste si le foncteur field_handler est nul avant de l�appeler. Par contre, sans std::function, il faut passer par des pointeurs de fonctions, c�est beaucoup plus pourri au niveau de la syntaxe.
05/11/2015, 16h24
Ehonn

Citation:

Envoy� par white_tentacle

Par contre, sans std::function, il faut passer par des pointeurs de fonctions, c�est beaucoup plus pourri au niveau de la syntaxe.

Pour simplifier la syntaxe, on peut prendre un param�tre template qui correspond � la fonction; �a fonctionne avec les pointeurs et r�f�rences de fonction et les foncteurs (et on met de c�t� la t�te de l'erreur si l'utilisateur ne passe pas une fonction avec la signature attendue).
06/11/2015, 10h57
stendhal666
@Paul_R:
1. pour enum class, tu peux utiliser enum tout simplement, cela enl�ve un peu de s�curit� mais ce n'est pas trop grave -tu peux aussi mettre l'enum dans son propre namespace pour �viter une confusion
2. pour std::function c'est un peu plus emb�tant, mais sans plus. Tu peux ajouter un membre de la classe csv_traits dans ton parser:
Code:

1 2 3 4 5 6 template <class csv_traits> class Parser { ... csv_traits traits_; ... };
et d�finir les fonctions is_seprator et autres dans ton csv_traits personnalis�:
Code:

1 2 3 4 5 6 class my_traits { ... bool is_separator(const char_type c) { return c == ';' ; } etc. ... };
Dans ta fonction 'consume' tu appelles "traits_.is_separator(c)."

3. pour les fonctions call_handler, elles sont d�finies dans le parser, par exemple:
Code:

1 2 3 4 class Parser { ... call_field_handler { data_handler.handle_field(last_value); traits_.truncate(last_value); } };

@white_tentacle:
Excellent article vraiment, hyper complet avec le profilage!

Une question sur la conception: pourquoi ne pas param�trer le parser avec les csv_traits et le data_handler?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
template <typename CsvTraits, typename DataHandler>
class Parser {
 
private:
  DataHandler& dh_;
  typename CsvTraits::string_type last_value;
  ST state;
 
public:
  Parser(DataHandler& dh) : dh_(dh), state(INIT) {}
  void parse(const typename CsvTraits::string_type&);
 
private:
  void consume(const typename CsvTraits::char_type& c);
  void end_of_data();
 
  void call_record_handler();
  void call_line_handler();
  void call_error();
 
};

Ensuite, en mettant un DataHandler qui affiche simplement le fichier sur la console:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
struct DefaultHandlers {
 
  void handle_record(const std::string& s) {
    std::cout << s << " | ";
  }
  void handle_newline() {
    std::cout << std::endl;
  }
  void handle_error() {
    std::cout << "!! an error has occured !!" << std::endl;
  }
};

on pourrait l'utiliser ainsi:

Code:

1
2
3
4
5
6
7
8
9
int main() {
 
  std::string test = "123;\"123;\"\"123\"\"\";123\n123;123;123";
 
  DefaultHandlers dh;
  Parser<StlTraits, DefaultHandlers> p(dh);
  p.parse(test);
 
}

Il me semble que cela simplifie (moins de classes, entre autres) et qu'on ne perd pas en modularit�?

06/11/2015, 14h11
white_tentacle
Citation:

Envoy� par stendhal666

@white_tentacle:
Une question sur la conception: pourquoi ne pas param�trer le parser avec les csv_traits et le data_handler?

[snip]

Il me semble que cela simplifie (moins de classes, entre autres) et qu'on ne perd pas en modularit�?

Un choix. Comme tout choix, il a une part d�arbitraire :).

Il y a plusieurs raisons � �a :
- sortir le data_handler permet d�exporter le parseur CSV param�tr� pour std::string dans une biblioth�que (et donc, corriger les �ventuels bugs du parseur sans recompiler l�utilisateur)
- cela permet aussi de r�duire la taille du code : le compilateur va sinon g�n�rer une classe par handler, et tout autant de symboles en plus.

N�anmoins, ta remarque est tr�s pertinente, et en proc�dant ainsi on doit probablement permettre des optimisations impossibles avec ce que j�ai propos�. Id�alement, je la ferai plut�t de la sorte :
Code:

1 2 3 4 template <typename CsvTraits, typename DataHandler> class Parser : public DataHandler {
Pourquoi un h�ritage public ? Pour plusieurs raisons :
- cela permet d�enrichir l�interface du Parser. Dans cette optique, il est possible d��crire un ConfigurableDataHandler qui permet de retrouver le comportement actuel
- le 0-size optimization : si sizeof(DataHandler) == 0, je n�augmente pas la taille de ma classe

En proc�dant ainsi on a le beurre et l�argent du beurre : la flexibilit� run-time ou compile-time.
07/11/2015, 14h20
bretus

Citation:

Envoy� par white_tentacle

Il y a plusieurs raisons � �a :
- sortir le data_handler permet d�exporter le parseur CSV param�tr� pour std::string dans une biblioth�que (et donc, corriger les �ventuels bugs du parseur sans recompiler l�utilisateur)
- cela permet aussi de r�duire la taille du code : le compilateur va sinon g�n�rer une classe par handler, et tout autant de symboles en plus.

J'aurais bien une autre raison : Avec le traits, comment est-ce qu'on permet � l'utilisateur de choisir le s�parateur dans une interface graphique? On fait du type erasure pour masquer un typage trop fort?

Je pense qu'il faut toujours se poser la question : Est-ce que je veux pouvoir changer au runtime. Si oui, la template est rarement la bonne id�e.

Quitte � sortir les param�tres, je ferais plut�t un "CSVFormat" (separator, closure, charset, etc.). C'est un type � part enti�re, son contenu et son code ne varie pas : Pas besoin de template.
09/11/2015, 12h32
white_tentacle

Citation:

Envoy� par bretus

Je pense qu'il faut toujours se poser la question : Est-ce que je veux pouvoir changer au runtime. Si oui, la template est rarement la bonne id�e.

En effet, mais le template n�emp�che pas forc�ment la configuration au run-time. La technique que j�ai d�crite, consistant � h�riter publiquement de la classe de traits/politique, permet � celle-ci d�enrichir l�interface et donc de rendre configurable ce qui au d�part �tait statique. Le tout sans type-erasure. J�ai la configuration run-time, si je la d�sire uniquement.

Citation:

Quitte � sortir les param�tres, je ferais plut�t un "CSVFormat" (separator, closure, charset, etc.). C'est un type � part enti�re, son contenu et son code ne varie pas : Pas besoin de template.

Il y a besoin de template car le code (g�n�r�) ne peut pas �tre raisonnablement le m�me en fonction du charset (si sizeof(char_type) change, �a devient compliqu� � sauf � tout convertir vers le plus grand (int32)). Ici, j�ai d�cid� de d�porter la gestion du charset en-dehors de la classe, car l�analyse faite s�y pr�te bien. Le choix serait diff�rent si ce n��tait pas le cas. Encore une fois, dans tout choix il y a une part d�arbitraire, �a ne veut pas dire que les autres solutions sont mauvaises.

Pour la petite histoire, ce choix de template vient � l�origine de la volont� (besoin r�el) de pouvoir g�rer � la fois std::string et QString comme classe de cha�ne de caract�res (et les deux de mani�re efficace). Ce serait compliqu� sans templates (loin d��tre impossible cela dit) et vraisemblablement moins efficace au final.
16/06/2016, 09h59
derf_r

Bonjour

Est ce que je code que tu proposes est sous la m�me licence que ton article ?
J'aimerai m'en servir d'en une appli et je voudrai �tre s�r de bien respecter la licence que tu as choii.

Fr�d�ric

Ne pas tenir compte de cette question ...

Re

Est ce que dans :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 class csv_data_handler { bool has_headers_; csv_data& data_; bool at_beginning_of_line; bool at_first_line; public: bool field_handler(std::string const& s) { double value; if(at_first_line && has_headers_) { data_.headers_.push_back(s); }
Il ne faudrait pas un ! ici ? :

Code:

if(at_first_line && !has_headers_)

Merci d'avance
Fr�d�ric

Voir 40 message(s) de cette discussion en une page