Traitement sur les fichiers.txt en C++

Version imprimable

30/01/2017, 12h39
nizoux

Traitement sur les fichiers.txt en C++

Bonjour ,
Je souhaite avoir votre opinion sur une méthode pratique afin d'extraire les dates respectives des fichiers.txt se trouvant dans un répertoire et stocker les dates dans un vector <string> sans qu'il y ait répétition.
Exemple des noms de fichiers:
MSD.NONE.2016-01-02.1994.txt
MSD.NONE.2016-01-02.1993.txt
MSD.NONE.2016-01-02.1996.txt
MSD.NONE.2016-01-05.1994.txt
MSD.NONE.2016-01-04.1994.txt
MSD.NONE.2017-01-02.1994.txt
MSD.NONE.2017-01-25.1994.txt
MSD.NONE.2017-01-25.1994.txt
MSD.NONE.2017-01-05.1994.txt

Pour cet exemple le vector doit contenir comme string les dates :
2016-01-02 ; 2016-01-05 ; 2016-01-04 ; 2017-01-02 ; 2017-01-25 ; 2017-01-05

Comme vous avez pu le constater il n y a pas de répétition.
Y-a t-il une méthode pour faire simple concernant l’extraction des chaînes
Merci pour votre aide , toute idée serait la bienvenue
30/01/2017, 12h45
ternel

Procède par ordre.

Comment ferais-tu pour extraire toutes les dates?

Une fois que tu sais le faire, il y a deux choix:
ne pas introduire de doublon pendant l'extraction, ou supprimer les doublons après l'extraction complète.

Les deux peuvent avoir leurs intérêts, mais je préfère la première, quand j'ai le choix.

Ta première question est bien d'obtenir la liste des fichiers du répertoire.
Pour cela, la meilleure solution est probablement de passer par Boost.Filesystem.
30/01/2017, 13h04
nizoux

Merci pour ton intervention.
Tout d'abord je vais catch tous les noms du répertoire via une méthode utilisant la bilbio Boost comme vous avez dit avant de les mettre dans le vector<string> on mettra une condition permettant de vérifier si il y a un doublon , ensuite pour extraire uniquement la date a vrai dire je n'ai aucune idée pour l'instant peut-être penser à décomposer la chaîne ??
30/01/2017, 14h54
Bysbobo

Vu que tous les noms que tu nous as donné sont syntaxiquement identiques, tu peux simplement les récupérer via un substr() du nom total ;)
30/01/2017, 15h42
ternel

Ta solution est assez bonne.

A toi de voir ce qui change ou non dans le nom de fichier, et ce qui doit être pris en compte pour le doublonnage.

Si seule la date change, et le chiffre suivant change, et seule la date t'intéresse, un substring bien visé suffit.

Si tu es sous linux, une commande telle que ls | cut -d. -f3 | sort -u affiche la liste demandée, et en rajoutant > liste_date.csv au bout, cette liste est écrite dans un fichier.
Tu n'as plus qu'a lire ligne à ligne ce fichier pour avoir ta réponse.

Pour Windows, la même chose doit pouvoir être faite en batch ou PowerShell, mais je ne connais pas assez ces langages.
30/01/2017, 16h55
nizoux

Merci à tous pour votre contribution et à @ternel pour ses explications détaillées.

Salut,

Juste une petite question idiote, mais... es tu obligé de placer tes chaines de caractères dans un élément de type std::vector :question:

Car, si tu veux éviter les doublons (et, accessoirement, avoir une recherche dichotomique), la meilleure collection à utiliser est sans doute std::set; quitte à tout remettre dans un std::vector une fois que tu as dressé la liste complète ;)

Le tout, c'est qu'il faut voir quels sont tes impératifs : vas tu passer ton temps à ajouter ou supprimer des dates (de prime abord, je dirais que non), à effectuer des recherches, ou à parcourir toutes ces dates "de la première à la dernière" :question:

Si tu effectues essentiellement des recherches, la recherche en O(log(n)) de std::set pourra sans doute contrebalancer les cache-misses du à la non contiguïté des données.

Si tu passes ton temps à parcourir toutes ces dates de la première à la dernière, la contiguïté des données en mémoire semble pour le moins importante, et un std::vector sera sans doute essentiel pour éviter les cache-misses

Quoi qu'il en soit, il est aussi possible d'obtenir une recherche dichotomique sur un std::vector à condition qu'il est trié, ce qui permet d'avoir le "meilleur des deux mondes"; à ceci près que, selon le compilateur que tu vas utiliser, il se peut que le contenu de la chaine de caractères (le char * sous-jacent) soit créé en ayant recours à l'allocation dynamique de la mémoire, si bien que les données ne seront de toutes façons pas réellement contiguës en mémoire.

En plus, la comparaison de chaines de caractères est -- classiquement -- très mauvaise en termes de performances: vu le format de tes dates, tu es systématiquement parti pour avoir quinze comparaisons par date!!!

Or, il serait sans doute possible de n'avoir besoin que de quatre comparaisons avec la structure adéquate, sans oublier qu'elle pourrait aussi garantir la contiguïté des données en mémoire.

Cette structure pourrait prendre la forme de
Code:

1 2 3 4 5 6 struct MaStructure{ int annee; int mois; int jour; int id; // les quatre derniers chiffres };
et il suffirait alors de coder l'opérateur < sous la forme de
Code:

1 2 3 4 5 6 bool operator < (MaStructure const & a, MaStructure const & b){ return a.annee < b.annee || (a.annee == b.annee && a.mois <b.mois) || (a.annee == b.annee && a.mois == b.mois && a.jour < b.jour) || (a.annee == b.annee && a.mois == b.mois && a.jour == b.jour && a.id < b.id); }
pour disposer de "tout ce qu'il faut" pour en garantir l'unicité ;)

01/02/2017, 09h50
ternel
Notons qu'avec C++11, il y a plus simple pour l'opérateur de comparaison:
Code:

1 2 3 bool operator < (MaStructure const & a, MaStructure const & b){ return std::tie(a.annee, a.mois, a.jour, a.id) < std::tie(b.annee, b.mois, b.jour, b.id); }
En effet, tie crée un tuple de références, et les tuples sont comparables (si tous leurs éléments le sont), dans l'ordre des éléments.
01/02/2017, 11h15
koala01

En effet... je ne pense pas assez souvent à tie :P

Ceci dit, au final, cela reviendra au même, car la logique de comparaison du tuple est la même que celle que j'ai décrite ;)
01/02/2017, 11h21
ternel

C'est justement parce que ca revient au même que c'est intéressant.

Par contre, question performance, ca mériterait peut-être une petite investigation.

Je viens de faire une comparaison de codes assembleurs.

MaStructure.cpp :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
 
struct MaStructure
{
	int annee;
	int mois;
	int jour;
	int id; // les quatre derniers chiffres
};
 
#ifdef EXPRESSION_BOOLEENNE_DEVELOPPEE
bool operator<(MaStructure const& a, MaStructure const& b)
{
	return a.annee < b.annee ||
		(a.annee == b.annee && a.mois < b.mois) ||
		(a.annee == b.annee && a.mois == b.mois && a.jour < b.jour) ||
		(a.annee == b.annee && a.mois == b.mois && a.jour == b.jour && a.id < b.id);
}
#endif
 
#ifdef EXPRESSION_BOOLEENNE_FACTORISEE
bool operator<(MaStructure const& a, MaStructure const& b)
{
	return
		a.annee < b.annee || (a.annee == b.annee && (
		a.mois  < b.mois  || (a.mois  == b.mois  && (
		a.jour  < b.jour  || (a.jour  == b.jour  && (
		a.id    < b.id
		))))));
}
#endif
 
#ifdef AVEC_TIE
#include <tuple>
bool operator<(MaStructure const& a, MaStructure const& b){
	return std::tie(a.annee, a.mois, a.jour, a.id) < std::tie(b.annee, b.mois, b.jour, b.id);
}
#endif
 
#ifdef TOUT_EN_UN_INT
#include <climits>
static_assert(sizeof(int)*CHAR_BIT >= 32);
bool operator<(MaStructure const& a, MaStructure const& b)
{
	// Inspiré de : https://www.developpez.net/forums/d1609952/c-cpp/cpp/declaration-operateurs-l-objet-courant/#post8789609
	return
		((((a.annee * 16 + a.mois) * 32) + a.jour) * 16 * 1024) + a.id
			<
		((((b.annee * 16 + b.mois) * 32) + b.jour) * 16 * 1024) + b.id;
}
#endif

Commandes exécutées avec GCC 6.3.0 :

Code:

1
2
3
4
g++ -O3 -S MaStructure.cpp -DEXPRESSION_BOOLEENNE_DEVELOPPEE -o EXPRESSION_BOOLEENNE_DEVELOPPEE.s
g++ -O3 -S MaStructure.cpp -DEXPRESSION_BOOLEENNE_FACTORISEE -o EXPRESSION_BOOLEENNE_FACTORISEE.s
g++ -O3 -S MaStructure.cpp -DAVEC_TIE                        -o AVEC_TIE.s
g++ -O3 -S MaStructure.cpp -DTOUT_EN_UN_INT                  -o TOUT_EN_UN_INT.s

Les trois premiers fichiers générés sont assez similaires.
Ils ont chacun 6 branchements conditionnels.
Au niveau de la taille, le 1er est un peu plus grand que le 2e qui est un peu plus grand que le 3e.

TOUT_EN_UN_INT.s, sans surprise, n'a aucun branchement conditionnel.
En taille, il est plus petit que les trois premiers fichiers.

Voici le contenu des fichiers :

EXPRESSION_BOOLEENNE_DEVELOPPEE.s :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
	.file	"MaStructure.cpp"
	.text
	.p2align 4,,15
	.globl	_ZltRK11MaStructureS1_
	.def	_ZltRK11MaStructureS1_;	.scl	2;	.type	32;	.endef
	.seh_proc	_ZltRK11MaStructureS1_
_ZltRK11MaStructureS1_:
.LFB0:
	.seh_endprologue
	movl	$1, %eax
	movl	(%rdx), %r8d
	cmpl	%r8d, (%rcx)
	jl	.L1
	movl	$0, %eax
	je	.L12
.L1:
	ret
	.p2align 4,,10
.L12:
	movl	$1, %eax
	movl	4(%rdx), %r9d
	cmpl	%r9d, 4(%rcx)
	jl	.L1
	movl	$0, %eax
	jne	.L1
	movl	$1, %eax
	movl	8(%rdx), %r10d
	cmpl	%r10d, 8(%rcx)
	jl	.L13
	je	.L4
	xorl	%eax, %eax
	ret
	.p2align 4,,10
.L13:
	ret
	.p2align 4,,10
.L4:
	movl	12(%rdx), %eax
	cmpl	%eax, 12(%rcx)
	setl	%al
	ret
	.seh_endproc
	.ident	"GCC: (GNU) 6.3.0"

EXPRESSION_BOOLEENNE_FACTORISEE.s :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
	.file	"MaStructure.cpp"
	.text
	.p2align 4,,15
	.globl	_ZltRK11MaStructureS1_
	.def	_ZltRK11MaStructureS1_;	.scl	2;	.type	32;	.endef
	.seh_proc	_ZltRK11MaStructureS1_
_ZltRK11MaStructureS1_:
.LFB0:
	.seh_endprologue
	movl	$1, %eax
	movl	(%rdx), %r8d
	cmpl	%r8d, (%rcx)
	jl	.L1
	movl	$0, %eax
	je	.L10
.L1:
	ret
	.p2align 4,,10
.L10:
	movl	$1, %eax
	movl	4(%rdx), %r9d
	cmpl	%r9d, 4(%rcx)
	jl	.L1
	movl	$0, %eax
	jne	.L1
	movl	$1, %eax
	movl	8(%rdx), %r10d
	cmpl	%r10d, 8(%rcx)
	jl	.L1
	movl	$0, %eax
	jne	.L1
	movl	12(%rdx), %eax
	cmpl	%eax, 12(%rcx)
	setl	%al
	ret
	.seh_endproc
	.ident	"GCC: (GNU) 6.3.0"

AVEC_TIE.s :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
	.file	"MaStructure.cpp"
	.text
	.p2align 4,,15
	.globl	_ZltRK11MaStructureS1_
	.def	_ZltRK11MaStructureS1_;	.scl	2;	.type	32;	.endef
	.seh_proc	_ZltRK11MaStructureS1_
_ZltRK11MaStructureS1_:
.LFB1223:
	.seh_endprologue
	movl	$1, %eax
	movl	(%rdx), %r8d
	cmpl	%r8d, (%rcx)
	jl	.L1
	movl	$0, %eax
	jg	.L1
	movl	$1, %eax
	movl	4(%rdx), %r9d
	cmpl	%r9d, 4(%rcx)
	jl	.L1
	movl	$0, %eax
	jg	.L1
	movl	$1, %eax
	movl	8(%rdx), %r10d
	cmpl	%r10d, 8(%rcx)
	jl	.L1
	movl	$0, %eax
	jg	.L1
	movl	12(%rdx), %eax
	cmpl	%eax, 12(%rcx)
	setl	%al
.L1:
	ret
	.seh_endproc
	.ident	"GCC: (GNU) 6.3.0"

TOUT_EN_UN_INT.s :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
	.file	"MaStructure.cpp"
	.text
	.p2align 4,,15
	.globl	_ZltRK11MaStructureS1_
	.def	_ZltRK11MaStructureS1_;	.scl	2;	.type	32;	.endef
	.seh_proc	_ZltRK11MaStructureS1_
_ZltRK11MaStructureS1_:
.LFB1:
	.seh_endprologue
	movl	(%rcx), %eax
	sall	$4, %eax
	addl	4(%rcx), %eax
	sall	$5, %eax
	addl	8(%rcx), %eax
	sall	$14, %eax
	addl	12(%rcx), %eax
	movl	%eax, %ecx
	movl	(%rdx), %eax
	sall	$4, %eax
	addl	4(%rdx), %eax
	sall	$5, %eax
	addl	8(%rdx), %eax
	sall	$14, %eax
	addl	12(%rdx), %eax
	cmpl	%eax, %ecx
	setl	%al
	ret
	.seh_endproc
	.ident	"GCC: (GNU) 6.3.0"

EDIT 2017-02-02-01h54 : Avec le code :

Code:

1
2
3
4
5
6
7
8
9
10
bool operator<(MaStructure const& a, MaStructure const& b)
{
	// Notez l'utilisation des <= à la place des ==.
	return
		a.annee < b.annee || (a.annee <= b.annee && (
		a.mois  < b.mois  || (a.mois  <= b.mois  && (
		a.jour  < b.jour  || (a.jour  <= b.jour  && (
		a.id    < b.id
		))))));
}

l'assembleur généré est identique à celui généré par la version qui utilise std::tie.

02/02/2017, 03h16
koala01

Citation:

Envoyé par Pyramidev

Je viens de faire une comparaison de codes assembleurs.

<snip>
l'assembleur généré est identique à celui généré par la version qui utilise std::tie.

Y a donc plus qu'à faire tourner un grand nombre de fois chacun de ces code sur un grand nombre de données pour essayer d'en faire ressortir des statistiques de performances correctes :D

Car, l'un dans l'autre, neuf lignes d'assembleurs de plus ou de moins peuvent très bien ne pas faire une énorme différence, voire, meme, ne pas faire une différence dans le sens que l'on croit, lorsqu'il s'agit détiquettes (L1, L10, L ...) et de sauts conditionnels ou non (jl, je, jne)

Et l'idéal serait -- bien sur -- de faire des tests avec des données "presque triées", des données "modérément mélangées" et des données "très mélangées"... Car, à mon sens, si des différences visibles doivent apparaitre, c'est à ce niveau là qu'on les verra ;)