Aujourd'hui j'ai une nouvelle question. J'ai un peu cherché et je vois pas
la bonne manière de faire ceci...
Je lis un fichier et j'ai une entrée de ce genre :
12 87
4783 49
1 0
429 452
Il s'agit de récupérer les deux nombres à chaque ligne. En Perl, c'est assez
aisé de le faire en utilisant une expression régulière. En C++, j'imagine
qu'il y a peut-etre une possibilité de faire ça, donc je préfère demander
avant de recoder un parseur.
Je vous remercie de votre aide une nouvelle fois ;)
Aujourd'hui j'ai une nouvelle question. J'ai un peu cherché et je vois pas la bonne manière de faire ceci...
Je lis un fichier et j'ai une entrée de ce genre : 12 87 4783 49 1 0 429 452
Il s'agit de récupérer les deux nombres à chaque ligne. En Perl, c'est assez aisé de le faire en utilisant une expression régulière. En C++, j'imagine qu'il y a peut-etre une possibilité de faire ça, donc je préfère demander avant de recoder un parseur.
Je vous remercie de votre aide une nouvelle fois ;)
Il n'y a pas (encore?) d'expressions régulières en C++ de base. Pour un cas comme celui-ci, une simple utilisation des string::find_first_of, find_last_not_of et substr peuvent probablement suffire.
Sinon, un parseur d'expressions régulières est disponible sur boost::regex.
-- Loïc
TigrouMeow wrote:
Bonjour,
Aujourd'hui j'ai une nouvelle question. J'ai un peu cherché et je vois pas
la bonne manière de faire ceci...
Je lis un fichier et j'ai une entrée de ce genre :
12 87
4783 49
1 0
429 452
Il s'agit de récupérer les deux nombres à chaque ligne. En Perl, c'est assez
aisé de le faire en utilisant une expression régulière. En C++, j'imagine
qu'il y a peut-etre une possibilité de faire ça, donc je préfère demander
avant de recoder un parseur.
Je vous remercie de votre aide une nouvelle fois ;)
Il n'y a pas (encore?) d'expressions régulières en C++ de base. Pour un
cas comme celui-ci, une simple utilisation des string::find_first_of,
find_last_not_of et substr peuvent probablement suffire.
Sinon, un parseur d'expressions régulières est disponible sur boost::regex.
Aujourd'hui j'ai une nouvelle question. J'ai un peu cherché et je vois pas la bonne manière de faire ceci...
Je lis un fichier et j'ai une entrée de ce genre : 12 87 4783 49 1 0 429 452
Il s'agit de récupérer les deux nombres à chaque ligne. En Perl, c'est assez aisé de le faire en utilisant une expression régulière. En C++, j'imagine qu'il y a peut-etre une possibilité de faire ça, donc je préfère demander avant de recoder un parseur.
Je vous remercie de votre aide une nouvelle fois ;)
Il n'y a pas (encore?) d'expressions régulières en C++ de base. Pour un cas comme celui-ci, une simple utilisation des string::find_first_of, find_last_not_of et substr peuvent probablement suffire.
Sinon, un parseur d'expressions régulières est disponible sur boost::regex.
-- Loïc
David
Aujourd'hui j'ai une nouvelle question. J'ai un peu cherché et je vois pas la bonne manière de faire ceci...
Je lis un fichier et j'ai une entrée de ce genre : 12 87 4783 49 1 0 429 452
Il s'agit de récupérer les deux nombres à chaque ligne. En Perl, c'est assez aisé de le faire en utilisant une expression régulière. En C++, j'imagine qu'il y a peut-etre une possibilité de faire ça, donc je préfère demander avant de recoder un parseur.
Bonjour, imaginons que line contienne ta ligne ( "12 87" par exemple ), peut être un simple flux :
istringstream iss( line ); int i1, i2; iss >> i1 >> i2;
i1, et i2 devraient contenir les deux nombres présents sur dans la ligne.
Tu pourrais même lire ton fichier directement en récupérant les valeurs par deux pour chaque ligne.
Aujourd'hui j'ai une nouvelle question. J'ai un peu cherché et je vois pas
la bonne manière de faire ceci...
Je lis un fichier et j'ai une entrée de ce genre :
12 87
4783 49
1 0
429 452
Il s'agit de récupérer les deux nombres à chaque ligne. En Perl, c'est assez
aisé de le faire en utilisant une expression régulière. En C++, j'imagine
qu'il y a peut-etre une possibilité de faire ça, donc je préfère demander
avant de recoder un parseur.
Bonjour,
imaginons que line contienne ta ligne ( "12 87" par exemple ),
peut être un simple flux :
istringstream iss( line );
int i1, i2;
iss >> i1 >> i2;
i1, et i2 devraient contenir les deux nombres présents sur dans la ligne.
Tu pourrais même lire ton fichier directement en récupérant les valeurs
par deux pour chaque ligne.
Aujourd'hui j'ai une nouvelle question. J'ai un peu cherché et je vois pas la bonne manière de faire ceci...
Je lis un fichier et j'ai une entrée de ce genre : 12 87 4783 49 1 0 429 452
Il s'agit de récupérer les deux nombres à chaque ligne. En Perl, c'est assez aisé de le faire en utilisant une expression régulière. En C++, j'imagine qu'il y a peut-etre une possibilité de faire ça, donc je préfère demander avant de recoder un parseur.
Bonjour, imaginons que line contienne ta ligne ( "12 87" par exemple ), peut être un simple flux :
istringstream iss( line ); int i1, i2; iss >> i1 >> i2;
i1, et i2 devraient contenir les deux nombres présents sur dans la ligne.
Tu pourrais même lire ton fichier directement en récupérant les valeurs par deux pour chaque ligne.
Tu pourrais même lire ton fichier directement en récupérant les valeurs par deux pour chaque ligne.
Ce qui a le désavantage de ne pas détecter les erreurs de formatage en entrée.
if ( !file.eof() ) { // erreur de le fichier en entrée. }
devrait pouvoir détecter une erreur de formattage à la fin de la lecture du fichier.
drkm
David writes:
Tu pourrais même lire ton fichier directement en récupérant les valeurs par deux pour chaque ligne.
Ce qui a le désavantage de ne pas détecter les erreurs de formatage en entrée.
if ( !file.eof() ) { // erreur de le fichier en entrée. }
devrait pouvoir détecter une erreur de formattage à la fin de la lecture du fichier.
Et si tu lui présentes ceci en entrée :
1 2 3 4 5 6
c'est correct ou non ?
Les spécifications peuvent préciser si ce l'est ou non. Mais en général, si l'on dit « une séquence de lignes contenant chacune deux entiers séparés par une espace », on veut exactement cela.
De toute manière, on peut arriver en fin d'un fichier contenant une erreur de formatage. Par exemple :
1 2 3
--drkm
David <dfleury2@libertysurf.fr> writes:
Tu pourrais même lire ton fichier directement en récupérant les valeurs
par deux pour chaque ligne.
Ce qui a le désavantage de ne pas détecter les erreurs de
formatage
en entrée.
if ( !file.eof() ) {
// erreur de le fichier en entrée.
}
devrait pouvoir détecter une erreur de formattage à la fin de la lecture
du fichier.
Et si tu lui présentes ceci en entrée :
1
2
3 4 5
6
c'est correct ou non ?
Les spécifications peuvent préciser si ce l'est ou non. Mais en
général, si l'on dit « une séquence de lignes contenant chacune deux
entiers séparés par une espace », on veut exactement cela.
De toute manière, on peut arriver en fin d'un fichier contenant une
erreur de formatage. Par exemple :
Tu pourrais même lire ton fichier directement en récupérant les valeurs par deux pour chaque ligne.
Ce qui a le désavantage de ne pas détecter les erreurs de formatage en entrée.
if ( !file.eof() ) { // erreur de le fichier en entrée. }
devrait pouvoir détecter une erreur de formattage à la fin de la lecture du fichier.
Et si tu lui présentes ceci en entrée :
1 2 3 4 5 6
c'est correct ou non ?
Les spécifications peuvent préciser si ce l'est ou non. Mais en général, si l'on dit « une séquence de lignes contenant chacune deux entiers séparés par une espace », on veut exactement cela.
De toute manière, on peut arriver en fin d'un fichier contenant une erreur de formatage. Par exemple :
1 2 3
--drkm
David
Et si tu lui présentes ceci en entrée :
1 2 3 4 5 6
c'est correct ou non ?
Je dirais que le programme qui a généré le fichier d'entrée est faux, puisqu'il ne répond pas aux spécifications. "Il s'agit de récupérer les deux nombres à chaque ligne."
Les spécifications peuvent préciser si ce l'est ou non. Mais en général, si l'on dit « une séquence de lignes contenant chacune deux entiers séparés par une espace », on veut exactement cela.
D'accord mais c'est pas forcément au 'lecteur' de vérifier cela.
strcpy( 0, "CHAINE" );
J'ai un segfault, c'est strcpy qui est buggué ou moi qui m'en sert mal ?
Les spécifications parlaient de deux nombres par lignes, s'il n'y en a pas... comportement non spécifié.
De toute manière, on peut arriver en fin d'un fichier contenant une erreur de formatage. Par exemple :
1 2 3
Mais en effet, la solution par le istringstream est sûrement plus facile pour contrôler plus finement la validité du fichier.
Et si tu lui présentes ceci en entrée :
1
2
3 4 5
6
c'est correct ou non ?
Je dirais que le programme qui a généré le fichier d'entrée est faux,
puisqu'il ne répond pas aux spécifications.
"Il s'agit de récupérer les deux nombres à chaque ligne."
Les spécifications peuvent préciser si ce l'est ou non. Mais en
général, si l'on dit « une séquence de lignes contenant chacune deux
entiers séparés par une espace », on veut exactement cela.
D'accord mais c'est pas forcément au 'lecteur' de vérifier cela.
strcpy( 0, "CHAINE" );
J'ai un segfault, c'est strcpy qui est buggué ou moi qui m'en sert mal ?
Les spécifications parlaient de deux nombres par lignes, s'il n'y en
a pas... comportement non spécifié.
De toute manière, on peut arriver en fin d'un fichier contenant une
erreur de formatage. Par exemple :
1 2
3
Mais en effet, la solution par le istringstream est sûrement plus facile
pour contrôler plus finement la validité du fichier.
Je dirais que le programme qui a généré le fichier d'entrée est faux, puisqu'il ne répond pas aux spécifications. "Il s'agit de récupérer les deux nombres à chaque ligne."
Les spécifications peuvent préciser si ce l'est ou non. Mais en général, si l'on dit « une séquence de lignes contenant chacune deux entiers séparés par une espace », on veut exactement cela.
D'accord mais c'est pas forcément au 'lecteur' de vérifier cela.
strcpy( 0, "CHAINE" );
J'ai un segfault, c'est strcpy qui est buggué ou moi qui m'en sert mal ?
Les spécifications parlaient de deux nombres par lignes, s'il n'y en a pas... comportement non spécifié.
De toute manière, on peut arriver en fin d'un fichier contenant une erreur de formatage. Par exemple :
1 2 3
Mais en effet, la solution par le istringstream est sûrement plus facile pour contrôler plus finement la validité du fichier.
drkm
David writes:
Les spécifications peuvent préciser si ce l'est ou non. Mais en général, si l'on dit « une séquence de lignes contenant chacune deux entiers séparés par une espace », on veut exactement cela.
D'accord mais c'est pas forcément au 'lecteur' de vérifier cela.
Pour ma part, j'ai souvent une attitude plutôt défensive. Si je ne peut pas être sûr de mon entrée, j'essaie de détecter les erreurs le plus tôt possible.
Et si je me souviens bien de la discussion, il n'est pas dit que le PO est assuré que l'entrée est correcte [*]. Il me semble donc pertinant de soulever le fait que ta « solution » ne détecte pas les erreurs de formatage. Maintenant, libre au PO de savoir s'il en a besoin ou non.
[*] J'insiste sur le fait que personnellement, c'est une garantie que je n'ai jamais assumée. Mais j'imagine qu'il est utile de le faire dans certains cas particuliers.
--drkm
David <dfleury2@libertysurf.fr> writes:
Les spécifications peuvent préciser si ce l'est ou non. Mais en
général, si l'on dit « une séquence de lignes contenant chacune deux
entiers séparés par une espace », on veut exactement cela.
D'accord mais c'est pas forcément au 'lecteur' de vérifier cela.
Pour ma part, j'ai souvent une attitude plutôt défensive. Si je ne
peut pas être sûr de mon entrée, j'essaie de détecter les erreurs le
plus tôt possible.
Et si je me souviens bien de la discussion, il n'est pas dit que le
PO est assuré que l'entrée est correcte [*]. Il me semble donc
pertinant de soulever le fait que ta « solution » ne détecte pas les
erreurs de formatage. Maintenant, libre au PO de savoir s'il en a
besoin ou non.
[*] J'insiste sur le fait que personnellement, c'est une garantie
que je n'ai jamais assumée. Mais j'imagine qu'il est utile de
le faire dans certains cas particuliers.
Les spécifications peuvent préciser si ce l'est ou non. Mais en général, si l'on dit « une séquence de lignes contenant chacune deux entiers séparés par une espace », on veut exactement cela.
D'accord mais c'est pas forcément au 'lecteur' de vérifier cela.
Pour ma part, j'ai souvent une attitude plutôt défensive. Si je ne peut pas être sûr de mon entrée, j'essaie de détecter les erreurs le plus tôt possible.
Et si je me souviens bien de la discussion, il n'est pas dit que le PO est assuré que l'entrée est correcte [*]. Il me semble donc pertinant de soulever le fait que ta « solution » ne détecte pas les erreurs de formatage. Maintenant, libre au PO de savoir s'il en a besoin ou non.
[*] J'insiste sur le fait que personnellement, c'est une garantie que je n'ai jamais assumée. Mais j'imagine qu'il est utile de le faire dans certains cas particuliers.
--drkm
Maxim
D'accord mais c'est pas forcément au 'lecteur' de vérifier cela.
Il ne faut jamais faire confiance aux données entrantes, pour éviter tout abus. Une grande partie des failles de sécurité viennent justement du manque de rigueur dans la vérification de l'input.
-- Maxim
D'accord mais c'est pas forcément au 'lecteur' de vérifier cela.
Il ne faut jamais faire confiance aux données entrantes, pour éviter
tout abus. Une grande partie des failles de sécurité viennent justement
du manque de rigueur dans la vérification de l'input.
D'accord mais c'est pas forcément au 'lecteur' de vérifier cela.
Il ne faut jamais faire confiance aux données entrantes, pour éviter tout abus. Une grande partie des failles de sécurité viennent justement du manque de rigueur dans la vérification de l'input.
-- Maxim
David
Il ne faut jamais faire confiance aux données entrantes,
Jamais ? Pour moi, ça dépend beaucoup d'où viennent les données entrantes. En l'occurence ici, ce qui semble être un simple exercice, il ne doit pas y avoir de trop grand danger.
pour éviter tout abus. Une grande partie des failles de sécurité viennent justement du manque de rigueur dans la vérification de l'input.
Il y a vraiment une faille de sécurite dans ce code ? int v1, v2; while( file >> v1 >> v2 ) ;
En effet, comme le souligne drkm, il semble délicat de valider le format en entrée du fichier mais à part ça.
Je ne suis pas spécialiste de le programmation en milieu 'hostile' mais je ne suis pas sûr qu'il soit facile de trouver un fichier en entrée permettant de prendre le contrôle de la machine ou autre. Autant en C, il faut faire plus attention, autant en C++ je suis beaucoup plus souple, les outils de la librairie C++ faisant le plus gros du travail.
David.
Il ne faut jamais faire confiance aux données entrantes,
Jamais ?
Pour moi, ça dépend beaucoup d'où viennent les données entrantes.
En l'occurence ici, ce qui semble être un simple exercice, il ne doit
pas y avoir de trop grand danger.
pour éviter
tout abus. Une grande partie des failles de sécurité viennent justement
du manque de rigueur dans la vérification de l'input.
Il y a vraiment une faille de sécurite dans ce code ?
int v1, v2;
while( file >> v1 >> v2 )
;
En effet, comme le souligne drkm, il semble délicat de valider le format
en entrée du fichier mais à part ça.
Je ne suis pas spécialiste de le programmation en milieu 'hostile'
mais je ne suis pas sûr qu'il soit facile de trouver un fichier en entrée
permettant de prendre le contrôle de la machine ou autre.
Autant en C, il faut faire plus attention, autant en C++ je suis beaucoup
plus souple, les outils de la librairie C++ faisant le plus gros du travail.
Il ne faut jamais faire confiance aux données entrantes,
Jamais ? Pour moi, ça dépend beaucoup d'où viennent les données entrantes. En l'occurence ici, ce qui semble être un simple exercice, il ne doit pas y avoir de trop grand danger.
pour éviter tout abus. Une grande partie des failles de sécurité viennent justement du manque de rigueur dans la vérification de l'input.
Il y a vraiment une faille de sécurite dans ce code ? int v1, v2; while( file >> v1 >> v2 ) ;
En effet, comme le souligne drkm, il semble délicat de valider le format en entrée du fichier mais à part ça.
Je ne suis pas spécialiste de le programmation en milieu 'hostile' mais je ne suis pas sûr qu'il soit facile de trouver un fichier en entrée permettant de prendre le contrôle de la machine ou autre. Autant en C, il faut faire plus attention, autant en C++ je suis beaucoup plus souple, les outils de la librairie C++ faisant le plus gros du travail.
David.
David
Pour ma part, j'ai souvent une attitude plutôt défensive. Si je ne peut pas être sûr de mon entrée, j'essaie de détecter les erreurs le plus tôt possible.
Ca parait raisonnable en effet.
Et si je me souviens bien de la discussion, il n'est pas dit que le PO est assuré que l'entrée est correcte [*]. Il me semble donc pertinant de soulever le fait que ta « solution » ne détecte pas les erreurs de formatage. Maintenant, libre au PO de savoir s'il en a besoin ou non.
[*] J'insiste sur le fait que personnellement, c'est une garantie que je n'ai jamais assumée. Mais j'imagine qu'il est utile de le faire dans certains cas particuliers.
Franchement, je n'ai jamais développer en milieu disons 'hostile' où les utilisateurs chercheraient volontairement à utiliser d'éventuelles failles à des fins malhonnêtes.
Mais en effet, les solutions que je proposais ne sont pas pourvues de contrôle au niveau du format de fichier. je pensais pas que cela soit nécessaire pour un simple exemple de ce style, et comme je le dis à Maxim, le risque encouru est IMHO négligeable. Au pire le résultat ne sera pas celui attendu.
Eventuellement si l'OP le souhaite, on pourra réfléchir à une solution permettant de valider le format du fichier en même temps que sa lecture. (sans pour autant utiliser les regexp qui me semblent disproportionnées dans ce contexte).
David.
Pour ma part, j'ai souvent une attitude plutôt défensive. Si je ne
peut pas être sûr de mon entrée, j'essaie de détecter les erreurs le
plus tôt possible.
Ca parait raisonnable en effet.
Et si je me souviens bien de la discussion, il n'est pas dit que le
PO est assuré que l'entrée est correcte [*]. Il me semble donc
pertinant de soulever le fait que ta « solution » ne détecte pas les
erreurs de formatage. Maintenant, libre au PO de savoir s'il en a
besoin ou non.
[*] J'insiste sur le fait que personnellement, c'est une garantie
que je n'ai jamais assumée. Mais j'imagine qu'il est utile de
le faire dans certains cas particuliers.
Franchement, je n'ai jamais développer en milieu disons 'hostile' où
les utilisateurs chercheraient volontairement à utiliser d'éventuelles
failles à des fins malhonnêtes.
Mais en effet, les solutions que je proposais ne sont pas pourvues
de contrôle au niveau du format de fichier.
je pensais pas que cela soit nécessaire pour un simple exemple de ce style,
et comme je le dis à Maxim, le risque encouru est IMHO négligeable.
Au pire le résultat ne sera pas celui attendu.
Eventuellement si l'OP le souhaite, on pourra réfléchir à une solution
permettant de valider le format du fichier en même temps que sa lecture.
(sans pour autant utiliser les regexp qui me semblent disproportionnées
dans ce contexte).
Pour ma part, j'ai souvent une attitude plutôt défensive. Si je ne peut pas être sûr de mon entrée, j'essaie de détecter les erreurs le plus tôt possible.
Ca parait raisonnable en effet.
Et si je me souviens bien de la discussion, il n'est pas dit que le PO est assuré que l'entrée est correcte [*]. Il me semble donc pertinant de soulever le fait que ta « solution » ne détecte pas les erreurs de formatage. Maintenant, libre au PO de savoir s'il en a besoin ou non.
[*] J'insiste sur le fait que personnellement, c'est une garantie que je n'ai jamais assumée. Mais j'imagine qu'il est utile de le faire dans certains cas particuliers.
Franchement, je n'ai jamais développer en milieu disons 'hostile' où les utilisateurs chercheraient volontairement à utiliser d'éventuelles failles à des fins malhonnêtes.
Mais en effet, les solutions que je proposais ne sont pas pourvues de contrôle au niveau du format de fichier. je pensais pas que cela soit nécessaire pour un simple exemple de ce style, et comme je le dis à Maxim, le risque encouru est IMHO négligeable. Au pire le résultat ne sera pas celui attendu.
Eventuellement si l'OP le souhaite, on pourra réfléchir à une solution permettant de valider le format du fichier en même temps que sa lecture. (sans pour autant utiliser les regexp qui me semblent disproportionnées dans ce contexte).
