Lecture de CSV en C++ : le faire « comme il faut »

Le concept d'une machine à états est assez simple. Plutôt que de stocker diverses valeurs relatives à tel ou tel événement qui vient de se produire (par exemple, « la valeur précédente était un séparateur »), on va stocker l'ensemble de ces informations dans une même donnée, qu'on appelle l'état courant. Cela nous fournit une vue plus synthétique de l'état réel dans lequel on est, et empêche d'avoir des combinaisons qui donneraient un état impossible ou incohérent (par exemple, « la valeur précédente était un séparateur » et « la valeur précédente était une fin de ligne » sont clairement incompatibles entre eux). L'état de notre machine va évoluer en fonction de ce qu'elle reçoit comme caractères à consommer.

On peut déjà considérer que notre machine va avoir trois états, les états classiques, à savoir :

• état initial ;
• état final ;
• état d'erreur.

Ensuite, il nous faut analyser les éléments qui vont provoquer un changement d'état. On peut assez facilement identifier la liste suivante :

• un séparateur, « , » ;
• un délimiteur, « " » ;
• une fin de ligne « \n » ;
• un début de commentaire « # » ;
• un autre caractère quelconque, qu'on notera « * ».

La fin de fichier sera gérée à part, puisqu'elle n'est pas un caractère à proprement parler dans le modèle que nous avons choisi. Nous allons donc définir ce que nous appelons des lexèmes (token en anglais), qui vont être au nombre de cinq, et qui seront utilisés par notre analyse.

Maintenant, nous allons, en partant de l'état initial, construire les états successifs en fonction de l'élément que nous consommons :

• un commentaire va nous mener à un nouvel état : « comment » ;
• un délimiteur va nous mener à un nouvel état : « quoted_record » ;
• une fin de ligne va nous mener à un nouvel état « new_line » ;
• un caractère quelconque va nous mener à un nouvel état « record » ;
• un séparateur signifie que le premier champ était vide, cela va donc nous mener à un état « between_record ».

Pour chacun de ces nouveaux états, nous allons répéter le processus, en agissant de la sorte :

• chaque fois que cela a du sens, nous allons réutiliser un état existant ;
• si cela n'est pas possible ou n'a pas de sens, nous allons créer un nouvel état.

Ce qui va caractériser l'état est une notion de déterminisme. Pour un état donné et une entrée consommée, il ne doit y avoir qu'un unique comportement. Si deux comportements sont possibles, cela signifie que l'état doit être scindé en deux.

Cela nous donne la machine à états suivante :

Le seul cas qui mérite un peu d'attention est le cas « quote_quoted_record ». En effet, lorsqu'on rencontre un guillemet au sein d'un champ entre guillemets, deux possibilités s'offrent à nous : soit c'est la fin du champ, soit c'est un guillemet doublé parce qu'il fait partie de la valeur du champ. Le seul moyen de faire la différence est d'aller voir le caractère suivant. Il nous faut donc cet état intermédiaire, afin de mémoriser qu'on vient de rencontrer un guillemet, et que donc le caractère suivant doit servir à déterminer la nature de ce guillemet, et agir en fonction.

Enfin, la machine précédente a été simplifiée : nous avons volontairement enlevé le cas de la fin de fichier. Il nous reste à le gérer. Cela revient à déterminer, en réalité, dans quelles conditions notre machine peut s'arrêter. En fait, elle peut s'arrêter à tout moment, sauf au sein d'un « quoted_record », qui ne serait pas terminé, ce qui est une erreur de syntaxe.

Pour l'instant, notre machine à états ne fait que consommer du contenu. Elle permet de valider qu'un CSV est bien formé, mais elle ne permet pas de le traiter. Nous allons y remédier en ajoutant des actions sur nos différentes transitions. Les actions vont être les suivantes :

• accumuler un caractère dans le champ ;
• terminer l'élément courant, notifier et le remettre à vide ;
• terminer l'enregistrement courant ;
• annoncer une erreur ;
• annoncer la fin de fichier ;
• Annoncer la fin d'un commentaire.

On retrouve en réalité la liste des actions qu'on a identifiées initialement, ce qui est assez logique. Nous allons maintenant mettre les actions sur les transitions, ce qui nous donne la machine suivante :

On remarque que les états « initial » et « newline » sont identiques (sauf pour la fin de fichier). On utilisera cette propriété ultérieurement pour factoriser le code.

Maintenant que nous avons notre machine à états, nous allons définir les différentes choses dont nous avons besoin pour l'analyse. Notre ensemble de lexèmes étant très réduit, nous allons simplement définir quatre fonctions, permettant d'identifier si un caractère est d'un type particulier. Ceci afin d'éviter de faire un premier test pour déterminer le lexème, puis un second pour tester ce lexème.

Cela nous donne les fonctions suivantes :

bool is_separator(char c);
bool is_new_line(char c);
bool is_double_quote(char c);
bool is_start_comment(char c);

Enfin, les différents états de la machine à états :

enum class csv_parser_state {
	initial,
	comment,
	record,
	quoted_record,
	quote_quoted_record,
	new_line,
	between_records
};

Les différentes erreurs que peut remonter notre parseur :

enum class csv_error {
	no_error = 0 /* pour pouvoir stocker ensemble l'erreur et l'absence d'erreur */,
	error_other,
	error_user_aborted,
	error_malformed_quoted_string,
	error_unterminated_quoted_string,
	error_empty_file
};

La définition des fonctions de rappel que notre parseur utilise :

typedef std::string string_type; // Pour pouvoir le changer plus facilement
std::function<bool(string_type const &)> comment_handler;
std::function<bool(string_type const &)> field_handler;
std::function<bool()> end_line_handler;
std::function<bool()> end_file_handler;
std::function<void(csv_error,int,int)> error_handler;

Quelques petites fonctions « utilitaires ». Ces fonctions seront utiles si l'on souhaite, par exemple, changer le type de chaîne utilisée. On verra dans la partie « Généricité » pourquoi on procède ainsi.

					void truncate(string_type & s) { s.clear(); }
					void append(string_type& s, char c) { s.push_back(c); }

Quelques petites fonctions utilitaires, pour des bouts de code qui vont se retrouver un peu partout :

void call_field_handler();
void call_end_line_handler();
void call_comment_handler();
void call_error_handler(csv_error err);
void update_line_counter();

Et enfin, la fonction principale d'analyse :

void csv_parser::consume(char c)
{
	current_pos_ += 1;
	switch(state_)
	{
        case initial:
        case new_line:
        {
        	if(is_separator(c))
            {
                call_field_handler();
                state_ = state::between_records;
            }
            else if(is_double_quote(c))
                state_ = state::quoted_record;
            else if(is_start_comment(c))
                state_ = state::comment;
            else if(is_new_line(c))
            {
                call_end_line_handler();
                state_ = state::new_line;
            }
            else
            {
            	last_value_.push_back(c);
                state_ = state::record;
            }
            break;
        }
        case state::record
        {
            if(is_separator(c))
            {
                call_field_handler();
                state_ = state::between_records;
            }
            else if(csvis_new_line(c))
            {
                call_field_handler();
                call_end_line_handler();
                state_ = state::new_line;
            }
            else
                last_value_.push_back(c);
            break;
        }
        case state::quoted_record:
        {
            if(is_double_quote(c))
                state_ = state::quote_quoted_record;
            else
            {
                if(is_new_line(c))
                    update_line_counter();
                last_value_.push_back(c);
            }
            break;
        }
        case state::quote_quoted_record:
        {
        	case state::quote_quoted_record:
	        {
	            if(is_separator(c))
	            {
	                call_field_handler();
	                state_ = state::between_records;
	            }
	            else if(is_double_quote(c))
                {
                    last_value_.push_back(c);
                    state_ = state::quoted_record;
                }
                else if(is_new_line(c))
                {
	                call_field_handler();
	                call_end_line_handler();
	                state_ = state::new_line;
	            }
	            else
	                call_error_handler(csv_error::malformed_quoted_string);
	            break;
	        }
        	
        }
        case state::between_records:
        {
            if(is_separator(c))
            {
                call_field_handler();
                state_ = state::between_records;
            }
            else if(is_double_quote(c))
                state_ = state::quoted_record;
            else if(is_new_line(c))
            {
                call_field_handler();
                call_end_line_handler();
                state_ = state::new_line;
            }
            else
            {
                last_value_.push_back(c);
                state_ = state::record;
            }
            break;
        }
        case state::comment:
        {
            if(is_new_line(c))
            {
                call_comment_handler();
                state_ = state::new_line;
                update_line_counter();
            }
            else
                csv_traits::append(last_value_, c);
            break;
        }
    }
}

Et enfin, le traitement de la fin de fichier :

void csv_parser::end_of_data()
{
    switch(state_)
    {
        case state::quote_quoted_record:
        case state::record:
        case state::between_records:
            call_field_handler();
            call_end_line_handler();
            break;
        case state::quoted_record:
            call_error_handler(csv_error::unterminated_quoted_string);
            break;
        case state::new_line:
            break;
        case state::comment:
            call_comment_handler();
            break;
        case state::initial:
            call_error_handler(csv_error::error_empty_file);
            break;
    }
    if(end_file_handler && error_ == csv_error::no_error)
    {
        if(!end_file_handler())
            error_ = csv_error::error_user_aborted;
    }
}

Parfois, certaines erreurs sont récupérables. Par exemple, un fichier CSV qui doit faire douze colonnes de large peut se retrouver avec, pour une raison quelconque, avec une ligne qui ferait treize colonnes de large. De même, certaines valeurs entières peuvent être hors limites, sans que cela ne soit catastrophique. Cette notion d'« avertissement », toutefois, est indépendante de notre parseur et se gère très bien au niveau du client.

La seule difficulté pour le client serait de localiser correctement les avertissements. En dehors du parseur, cela peut être un peu complexe. Nous verrons plus loin comment y remédier.

Afin que l'utilisateur de notre parseur puisse retrouver facilement les erreurs dans son fichier, il est nécessaire de lui donner des indications sur l'endroit où se trouvent les erreurs. Nous allons pour cela lui donner deux indications :

• la ligne où a lieu l'erreur/l'avertissement ;
• la colonne où elle a lieu.

À cet effet, nous allons rajouter à notre parseur deux compteurs, un pour les lignes et un pour les colonnes. Attention toutefois, le compteur de lignes doit être incrémenté à chaque nouvelle ligne, pas uniquement à la fin d'un enregistrement CSV. Quant au compteur de colonnes, il doit bien évidemment être remis à zéro à chaque changement de ligne, mais il se pose aussi un autre problème : comment gérer les caractères multi-octets ?

La première solution consiste à ne pas les gérer. Après tout, les caractères multi-octets ne sont pas si fréquents, et la position ne sera que légèrement fausse, ce qui pourrait être acceptable. Il est possible de faire mieux que cela, l'exercice est laissé au lecteur.

Comme nous l'avons vu, tous les traitements vont s'effectuer dans les fonctions de rappel appelées par le parseur CSV. L'enchaînement va être généralement quelque chose comme :

				field_handler("chaîne lue");
				field_handler("chaîne lue 2");
				field_handler("chaîne lue 3");
				end_line_handler();
				field_handler("colonne 1");
				field_handler("colonne 2");
				...

À partir de là, l'utilisateur est libre de faire tous les traitements qu'il désire. Pour simplement compter le nombre de champs dans le fichier CSV ainsi que le nombre d'enregistrements, on pourra simplement utiliser quelque chose comme :

				class csv_count {
					int nbFields;
					int nbLines;
				public:
					CsvCount() : nbFields(0), nbLines(0) {}
					bool handle_field(std::string const& field) { nbFields += 1; }
					bool handle_end_line() { nbLines += 1; }
					int number_of_fields() const { return nbFields; }
					int number_of_lines() const { return nbLines; }
				};

Il est très aisé, à partir de là, de, par exemple, vérifier qu'un enregistrement n'a pas un nombre trop important de colonnes. C'est la valeur de retour de la fonction « handle_field/handle_end_line » qui va servir à indiquer qu'un problème a eu lieu lors du traitement. Lorsqu'un problème survient, notre parseur va appeler le « error_handler » qui lui a été défini, en lui passant en paramètres la localisation et le type d'erreur.

Si on souhaite générer un niveau intermédiaire, de type avertissement, comme on l'a vu plus haut, il faut modifier le type de retour de « handle_field/handle_end_line » et rajouter un warning_handler.

Les sources de données CSV peuvent être nombreuses et diverses. Le plus fréquemment, on part d'un fichier qui est en local sur le disque dur. Mais cela ne représente qu'une infime partie des cas d'utilisation :

• fichier sur le réseau ;
• fichier récupéré depuis une requête http ;
• données lues depuis la console, redirigées depuis un autre programme ;
• etc.

L'approche « naïve » à base de getline s'accommode très mal de cette contrainte : en effet, il est impossible de savoir à l'avance où va se trouver le prochain saut de ligne. Aussi, sauf à charger toutes les données en mémoire au préalable, si celles-ci arrivent à la volée, il est très probable que getline coupe au milieu des données, parce qu'il est arrivé à la fin du buffer qu'on lui passe. Ou alors qu'il bloque, en attendant désespérément une fin de ligne qui met du temps à arriver, figeant totalement notre programme, nous forçant à éventuellement déporter la lecture dans un thread séparé, ce qui commence à beaucoup complexifier les choses.

Nous l'avons vu, notre parseur est conçu pour être alimenté caractère par caractère. Il peut être interrompu puis reprendre à tout moment de la lecture du fichier, puisqu'il conserve un état interne pour cela. Cette particularité va nous permettre de contourner toutes les difficultés évoquées plus haut, en effet :

• il n'y a pas besoin de savoir à l'avance quand sera la prochaine fin de ligne ;
• si un buffer est incomplet, ce n'est pas un problème : le parseur pourra reprendre où il en était, de manière totalement transparente. Et les fonctions de rappel appelées par le parseur ne verront même pas qu'il y a eu une interruption.

Il est ainsi possible d'intégrer notre parseur à tout système de lecture synchrone ou asynchrone, bloquant ou non bloquant, car celui-ci est totalement neutre de ce point de vue, et de par sa conception supporte parfaitement de traiter des données partielles. C'est un aspect très important dès que l'on veut traiter des données reçues depuis le réseau ou toute autre source de données « lente ».

La première chose dont nous allons avoir besoin est de définir ce qu'est notre csv_data. On peut raisonnablement estimer plusieurs choses :

• il parait raisonnable de stocker l'ensemble des enregistrements (« lignes » du fichier csv) dans un « tableau » et d'y fournir un accès par indice, ainsi que des itérateurs ;
• pour chaque enregistrement, de la même manière, chacun des champs devrait pouvoir être accédé de différentes manières. Soit par indice, soit par le nom de l'en-tête de la colonne, soit via des itérateurs ;
• l'utilisateur ne pourra pas modifier les données lues. C'est un choix arbitraire, il serait possible de faire autrement. Le lecteur est libre de procéder aux modifications adéquates. Toutefois, il parait beaucoup plus logique, si l'on souhaite modifier les données, de passer par une structure idoine, qu'on alimentera à l'aide du parseur plus « bas niveau ».

Nous allons donc définir plusieurs classes :

• une première pour stocker l'ensemble des données, qui sera responsable de la durée de vie de celles-ci. Appelons-la tout simplement csv_data ;
• une deuxième pour stocker les données relatives à un enregistrement unique. Celle-ci contiendra une référence vers la première (pour la liste des en-têtes), et les fonctions permettant d'accéder aux données.

VII-A-1. Classe csv_record▲

class csv_record {
	friend class csv_data; // csv_data a un accès privilégié aux données de cette classe, 
	                       // c'est elle qui l'initialise
	csv_data const& owner_;
	std::vector<std::string> fields_;
public:
	csv_record(csv_data const& owner) : owner_(owner) {}
	typedef std::vector<std::string>::const_iterator const_iterator;
	const_iterator begin() const;
	const_iterator end() const;
	std::string const& operator[](size_t i) const;
	boost::optional<std::string const&> operator[](std::string const& header) const;
	size_t size() const;
};

VII-A-2. Classe csv_data▲

class csv_data
{
	friend class csv_data_handler; // the handler, to fill data

    std::vector<csv_record> records_;
	std::vector<std::string> headers_;
	void new_record() { records_.emplace_back(*this); };
	void add_field(std::string const& field) { records_.back().add_field(field); };
public:
    typedef std::vector<csv_record>::const_iterator const_iterator;
    const_iterator begin() const;
    const_iterator end() const;
    csv_record const& operator[](size_t i);
    size_t size() const;
    std::vector<std::string> const& headers() const;
};

VII-A-3. Classe csv_data_handler▲

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)
    {
        if(at_first_line && has_headers_)
        {
            data_.headers_.push_back(s);
        }
        else
        {
            if(at_first_line)
                data_.headers_.push_back("header" + std::to_string(data_.headers_.size()));
            if(at_beginning_of_line)
            {
                data_.new_record();
                at_beginning_of_line = false;
            }
            data_.add_field(s);
        }
    }
    bool end_line_handler()
    {
        at_beginning_of_line = true;
        at_first_line = false;
    }

    csv_data_handler(csv_data& data, bool has_header_line, csv_parser & parser) :
        data_(data),
        has_headers_(has_header_line),
        at_beginning_of_line(true),
        at_first_line(true)
    {
        parser.field_handler = [this](std::string const& s) { return field_handler(s); };
        parser.end_line_handler = [this]() { return end_line_handler(); };
    }
};

Cette partie ne présente aucune difficulté, il s'agit simplement de lire un fichier et d'alimenter le parseur en conséquence. Ce peut être fait, par exemple avec le code suivant :

std::unique_ptr<dvp::csv_data> read_csv_file(std::string path, bool header_line)
{
    std::fstream f(path.c_str());
    std::unique_ptr<dvp::csv_data> data(new dvp::csv_data());
    dvp::csv_parser parser;
    dvp::csv_data_handler(*data, header_line, parser);
    char buf[16192];
    while(f.good() && !parser.error())
    {
        int nb = sizeof(buf);
        f.read(buf, nb);
        if(!f.good())
            nb = f.gcount();
        for(int i = 0; i < nb; ++i)
        {
            parser.consume(buf[i]);
        }
    }
    if(f.eof())
    {
        parser.end_of_data();
        if(parser.complete())
            return data;
    }
    return nullptr;
}

On l'a vu, le séparateur fait partie de la classe de traits. Donc, pour changer de séparateur, il faut changer de type de parseur. En fait, cela peut se révéler particulièrement gênant dans certains contextes, quand par exemple on veut proposer à l'utilisateur de choisir le séparateur au moment de la lecture du fichier.

Ce cas se gère en fait assez facilement, en faisant preuve d'un peu d'astuce. En effet, il suffirait que notre classe de traits puisse stocker le caractère en question, et adapter la fonction analyze_char en conséquence. Problème : notre classe csv_parser ne possède pas de membre de type « csv_traits ». Et celui-ci étant la plupart du temps vide, ce serait un gâchis de place.

Plutôt que d'utiliser un membre, nous allons donc utiliser un héritage privé. L'avantage est que si notre classe de traits est vide (le cas le plus fréquent), nous n'avons aucun coût supplémentaire.

Reste encore à voir comment on définit ce séparateur. Puisqu'on a utilisé un héritage privé, il n'est pas possible d'utiliser une méthode publique qui viendrait se « rajouter » à l'interface du parseur. En revanche, nous pouvons utiliser une fonction déjà existante, à savoir le constructeur, en utilisant une nouveauté de c++11, les « templates variadic » :

					template<typename... Args>
					csv_parser(Args... args) : csv_traits(args...) { }

Notre constructeur dépend désormais de notre classe de traits, et cela nous permet qu'il prenne, par exemple, un paramètre de type « char » étant le séparateur. Ce paramètre sera transmis au constructeur de la classe de base csv_traits, dans laquelle il sera stocké. Ceci est un exemple d'utilisation de ce mécanisme, mais celui-ci permet en réalité beaucoup plus, le tout étant laissé à l'imagination des utilisateurs de notre parseur.

Il est aussi possible de définir un héritage public pour la classe de traits, ce qui présenterait l'avantage de pouvoir enrichir l'interface (avec par exemple, une méthode pour récupérer le séparateur utilisé). L'inconvénient est que cela implique un polymorphisme dynamique qui fait peu de sens ici. Pour le cas particulier de récupérer le séparateur utilisé, on va plutôt rajouter une méthode dans notre parseur csv, qui fera appel à la méthode de la classe de traits.

Le choix qui a été fait ici, à savoir, d'utiliser des politiques statiques pour l'analyse, mais des fonctions de rappel pour le comportement utilisateur, relève, comme tous les choix, d'une part d'arbitraire et de compromis. On aurait très bien pu exiger de l'utilisateur de, plutôt que de fournir des fonctions de rappel pour field_handler, fournir ces fonctions sous forme d'une classe de politiques template. Il y a plusieurs raisons de ne pas le faire :

• en procédant ainsi, chaque parseur, lié à une fonction de rappel différente, serait d'un type différent. Cela peut réellement complexifier le code du client ;
• le gain de perf ne sera pas aussi conséquent que pour les fonctions utilitaires, appelées beaucoup plus souvent ;
• cela peut aussi augmenter de manière conséquente la taille occupée en mémoire par le code.

Néanmoins, cette approche permettrait certaines combinaisons intéressantes, en particulier en terme d'optimisations. Une solution de compromis serait d'utiliser des politiques statiques, mais de fournir par défaut une politique configurable équivalente à ce que nous avons introduit ici. L'exercice est laissé au lecteur.

Le fichier utilisé est un fichier de 1 600 004 lignes contenant chacune 48 colonnes, pour une taille totale de 460 801 152 octets.

La première chose à constater, c'est que les performances de notre parseur sont comparables à celles de libcsv, lorsqu'il est utilisé de la même manière (fonctions de rappel). Ensuite, il faut déplorer qu'il soit impossible de lire le fichier à l'aide de notre structure csv_data : l'occupation mémoire est tout simplement trop importante pour la machine de test. Cela est lié à l'utilisation des std::string (sur la même machine, allouer 76 800 192 « std::string » donne le même résultat : ça swappe à mort). Cela nous conforte dans l'idée que cette méthode ne peut s'appliquer que pour des fichiers de taille moyenne.

Enfin, le cas de getline est un peu particulier. Si on se contente juste de compter les « , » et les « \n », elle est bien la plus rapide. En revanche, si on souhaite se donner la possibilité d'exploiter toutes les données lues, elle devient plus lente que libcsv ou csv_parser.

Le fichier utilisé est un fichier de 7113 lignes, chacune d'entre elles faisant 19 623 caractères, répartis sur trois colonnes, soit 21 449 champs au total.

Peu de remarques particulières, si ce n'est que libcsv est étonnamment plus lent (il faudrait analyser le code, mais il est vraisemblable que la stratégie de réallocation de chaîne ne soit pas adaptée à des chaînes de caractères aussi grandes), et que csv_data se comporte très bien : l'empreinte mémoire étant plus réduite, la structure redevient parfaitement utilisable et on constate que ses performances sont plus que correctes. À l'inverse, getline est nettement plus rapide dans ce contexte.

Le but est, à partir des données suivantes :

12,34,46
34,76,28
1,87,32

D'obtenir la sortie suivante :

80
104
119

Le fichier utilisé fait 1 000 000 lignes, chacune de trois colonnes, pour une taille totale de 15 625 400 octets.

Là encore, on constate que notre parseur se comporte au même niveau que libcsv, et fait mieux que le code naïf écrit à l'aide de getline. La structure csv_data, qui elle impose de tout garder en mémoire, est logiquement beaucoup plus lente. Enfin, la ligne csv_int_parser mérite quelques commentaires.

En effet, dans ce dernier test, nous ne traitons que des entiers. Quel intérêt de construire une chaîne, pour ensuite la convertir en un entier ? Autant construire un entier directement. csv_int_parser utilise donc cette propriété, en fournissant une classe de traits un peu particulière, définie de la sorte :

struct csv_int_traits
{
    typedef int string_type;
    typedef char char_type;
    void append(int& val, char c)
    {
        val = val * 10 + (c - '0');
    }
    void truncate(int & val)
    {
        val = 0;
    }
	...
}

Ce qui permet tout simplement d'améliorer les performances de 40 % environ, le tout sans toucher à notre parseur lui-même, et d'atteindre des performances qui sont tout simplement inaccessibles avec libcsv, et qui demanderaient de refondre complètement le code utilisant std::getline.

Attention tout de même avec ce type d'approche : le code présenté en exemple est particulièrement naïf, aucune validation n'y est effectuée. Dans la réalité, il faudra donc prévoir un système de gestion d'erreur (par exemple, des exceptions, une gestion par valeur de retour n'étant pas prévue ici, quoique pouvant être implémentée facilement), qui peut engendrer un léger surcoût.

Si l'on devait tirer un rapide bilan de ces mesures de performances, certes forcément partielles, il serait le suivant :

• les performances de notre approche sont de manière générale un peu meilleures que celles de libcsv, assez similaires dans le cas général. C'est logique, car libcsv utilise une approche similaire à la notre, inclut un peu plus de contrôle d'erreur que ce que nous avons fait, ce qui peut expliquer certaines différences (quoique la différence dans le test 2 est vraisemblablement plutôt à chercher du côté de l'allocation mémoire) ;
• les performances en utilisant getline sont tantôt bien meilleures (dans des cas extrêmes), tantôt bien pires. Il serait logique qu'en améliorant chaque test, il soit possible de toujours faire mieux. Il ne faut néanmoins pas oublier qu'avec cette approche, on échoue sur certains fichiers csv ;
• l'approche csv_data présente un surcoût qui est largement plus fonction du nombre de chaînes traitées que de la taille de celles-ci. Ce surcoût est systématique et réel, et peut conduire dans certains cas à un échec complet du traitement. De plus, la consommation mémoire maximale du programme, non reportée ici, est bien évidemment de plusieurs ordres de grandeur supérieure avec cette approche ;
• l'approche que nous avons choisie, grâce à la généricité et l'usage de classe de traits, permet des optimisations intéressantes qui ne sont tout simplement pas réalisables avec libcsv, et qui demanderaient de repenser complètement la boucle de traitements dans une approche type getline.