Version imprimable
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
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:.
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.
Excellent, j'en avais justement besoin !
Merci beaucoup ! Ça va m'éviter quelques heures d'arrachage de cheveux et quelques litres de café... :mrgreen:
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).Citation:
Envoyé par MichaelREMY
Si tu veux faire tes traitements de manière asynchrone, rien ne change non plusCode:
2
3
4
5
6
7
8
9
10
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...Citation:
Envoyé par Iradrille
c'est un très bon article-tuto que vous avez écrit là.
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.Citation:
Envoyé par MichaelREMY
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 :Citation:
Envoyé par dragonjoker59
* 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.
moi qui ai toujours fait un get_line et un split, je vais peut être regarder le tuto... :D
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.
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...
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.
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).Citation:
Envoyé par white_tentacle
@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:
et définir les fonctions is_seprator et autres dans ton csv_traits personnalisé:Code:
2
3
4
5
6
Dans ta fonction 'consume' tu appelles "traits_.is_separator(c)."Code:
2
3
4
5
6
3. pour les fonctions call_handler, elles sont définies dans le parser, par exemple:
Code:
2
3
4
@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?
Ensuite, en mettant un DataHandler qui affiche simplement le fichier sur la console:Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
on pourrait l'utiliser ainsi:Code:
2
3
4
5
6
7
8
9
10
11
12
Il me semble que cela simplifie (moins de classes, entre autres) et qu'on ne perd pas en modularité?Code:
2
3
4
5
6
7
8
9
Un choix. Comme tout choix, il a une part d’arbitraire :).Citation:
Envoyé par stendhal666
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 :
Pourquoi un héritage public ? Pour plusieurs raisons :Code:
2
3
4
- 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.
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?Citation:
Envoyé par white_tentacle
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.
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:
Envoyé par bretus
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.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.
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.
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 :
Il ne faudrait pas un ! ici ? :Code:
2
3
4
5
6
7
8
9
10
11
12
13
Merci d'avanceCode:if(at_first_line && !has_headers_)
Frédéric
bonjour
ne pas tenir compte de ma question précédente
Désolé mais pour moi ce n'est pas un tutoriel et encore moins un cours car au final on apprend peu de choses tellement le code est incompréhensible.
Il aurait mérité plus d'explications et de détails...pour que ce soit un minimum ludique. :weird:
Joli le déterrage, alors que la dernière intervention datais de ... trois ans.Citation:
Envoyé par Polymergevertex
Ceci dit, nous sommes en face d'un article, qui explique parfaitement le point de vue de l'auteur. Il n'a jamais été question d'en faire un tutoriel ;)
Si le code t'a semblé obscure, je pencherais volontiers d'avantage pour le fait qu'il te manque quelques concepts de base ou quelque notions de C++ que pour autre chose.
Bien sur, étant particulièrement à l'aise avec le langage, je ne suis sans doute pas le mieux placé pour parler de la difficulté du code, mais je n'ai rien trouvé de bien compliqué dans les explications ;)
Enfin, il n'y a rien à faire: la programmation oscille entre la science exacte et l'art, ce qui fait que, au delà d'un certain niveau, la ludicité n'a plus vraiment sa place: elle doit la céder à l'exactitude. Et c'est le cas de cet article ;)
En relisant l'article, je vois que l'auteur demande à l'utilisateur de lui passer des callbacks pour décider quoi faire à chaque étape de lecture du fichier CSV :
Cette conception ne m'avait pas choqué à l'époque, mais elle me gène aujourd'hui. En fait, je trouve cette conception tout à fait justifiée pour l'époque où a été écrit cet article, en 2015, donc à l'époque du C++14. Mais je me dis qu'elle est surtout justifiée par les limitations du C++ de l'époque et de la bibliothèque standard de l'époque et qu'il faudra privilégier une autre approche en C++20.Code:
2
3
4
5
Je vais prendre un exemple basique et faire un parallèle avec le langage Python. Admettons qu'un fichier CSV représente une liste d'utilisateurs, sous la forme d'un utilisateur par ligne. Parmi les champs, l'un d'eux contient le nom de l'utilisateur et un autre vaut 0 ou 1 selon que l'utilisateur soit actif ou inactif. On veut afficher la liste des noms des utilisateurs actifs.
En Python, on peut facilement découper le code en plusieurs niveaux d'abstractions.
On peut partir de csv.reader qui retourne un itérable de listes de chaînes (une liste = une ligne ; une chaîne = une cellule). Appelons my_reader cet itérable.
Ensuite, si on définit une fonction fn convert_row_to_user(row: List[str]) -> User qui prend en paramètre une liste de chaînes et retourne un objet de type User, alors users = map(convert_row_to_user, my_reader) crée un itérable d'objets de type User à partir de l'itérable de départ.
Admettons que la classe User contienne une propriété active. On peut alors écrire active_users = filter(lambda user: user.active, users) pour créer un itérable d'objets de type User qui ne contient que les utilisateurs actifs.
Admettons que la classe User contienne une propriété name. On peut alors écrire active_user_names = map(lambda user: user.name, active_users) pour créer un itérable de chaînes qui correspond aux noms des utilisateurs actifs.
Précisons que l'évaluation est paresseuse : c'est en parcourant les éléments de l'itérable active_user_names qu'on lit les lignes du fichier CSV. Tant qu'on n'a pas encore atteint la fin de l'itérable, on n'a pas encore lu en entier le fichier CSV.
L'un des avantages est que l'on peut facilement découper le code en sous-fonctions réutilisables. Par exemple, on peut avoir une fonction get_active_user_names qui appelle une sous-fonction get_active_users qui appelle une fonction get_users.
Mais, si on remplace l'itérable de départ par un système de callbacks comme dans l'article, ça casse tout dans le code qui utilise le parseur de fichier CSV : au lieu d'écrire du beau code avec des fonctions décomposées en sous-fonctions comme on veut, de la propagation d'erreur lisible, des éventuelles boucles, etc., on se retrouve à coder une machine à états en partie monolithique dont la maintenabilité décroît avec la complexité du code qui est exécuté avant la fin de la lecture du fichier CSV.
En C++17, on pourrait concevoir le parseur de fichier CSV sous la forme d'un range dont les éléments auraient un type du genre std::variant<comment, field, end_line, error> (la fin du fichier se traduirait par la fin du range).
Par dessus, l'utilisateur pourrait créer un range dont chaque élément représente une ligne de fichier CSV. En cas d'erreur de lecture, on lance une exception. Ce type de code devrait être facilité en C++20 avec les coroutines.
Ensuite, pour que l'utilisateur puisse, comme dans l'exemple en Python, générer facilement un range d'utilisateurs par dessus le range de lignes puis générer facilement un range d'utilisateurs actifs par dessus le range d'utilisateurs, on devrait aussi avoir les équivalents de filter et map en C++20 (std::views::filter et std::views::transform). Il faudra faire attention à la gestion de la mémoire, mais le code devrait rester lisible.
Mais l'article présent date de 2015 où il n'y avait ni std::variant du C++17, ni les fonctionnalités sympathiques qui arriveront en C++20, donc c'est tout à fait normal que l'auteur ait choisi une conception avec un système de callbacks. Les limitations du langage conditionnent la manière à laquelle on conçoit les interfaces.