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 ;)
std::istringstream s( line ) ; line >> i >> j >> std::ws ;
Je connaissais pas l'utilisation de ws comme ça. Intéressant.
if ( ! line || line.peek() != EOF ) {
Pas sûr du line.peek(), probablement s.peek().
En fait, je me suis servi de line partout où il aurait fallu s :
s >> i >> j >> std::ws ; if ( !s || s.peek() != EOF ) { ... }
Aussi, on pourrait aussi bien utiliser get à la place de peek.
// erreur... }
En fait, si quelque part il y a une ligne qui manque un nombre, si tu ne vérifies pas ligne par ligne, tu ne détectes l'erreur qu'à la fin.
La question fondamentale, c'est qu'est-ce qu'on va faire avec les erreurs qu'on détecte. Mon expérience suggère qu'on va afficher l'erreur. Avec son numéro de ligne, pour que l'utilisateur peut le rétrouver facilement. Dans ce cas-là, la lecture ligne par ligne est tout à fait indiquée, pour faciliter aussi le comptage des lignes.
Ca parait très raisonnable. Mon expérience me ferait croire qu'il n'y aurait pas grand monde pour lire l'erreur afficher si le traitement n'indique pas une erreur claire (genre return != 0 dans le main).
Tout à fait. Il faut d'une part écrire un message clair sur std::cerr qui permet à l'utilisateur de rétrouver l'erreur, et de l'autre, souvent, terminer le programme avec un code d'erreur, pour que quelqu'un qui s'en sert dans un script peut arrêter le traitement.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
David <dfleury2@libertysurf.fr> wrote in message
news:<416c1712$0$28923$636a15ce@news.free.fr>...
std::istringstream s( line ) ;
line >> i >> j >> std::ws ;
Je connaissais pas l'utilisation de ws comme ça.
Intéressant.
if ( ! line || line.peek() != EOF ) {
Pas sûr du line.peek(), probablement s.peek().
En fait, je me suis servi de line partout où il aurait fallu s :
s >> i >> j >> std::ws ;
if ( !s || s.peek() != EOF ) { ... }
Aussi, on pourrait aussi bien utiliser get à la place de peek.
// erreur...
}
En fait, si quelque part il y a une ligne qui manque un nombre, si
tu ne vérifies pas ligne par ligne, tu ne détectes l'erreur qu'à la
fin.
La question fondamentale, c'est qu'est-ce qu'on va faire avec les
erreurs qu'on détecte. Mon expérience suggère qu'on va afficher
l'erreur. Avec son numéro de ligne, pour que l'utilisateur peut le
rétrouver facilement. Dans ce cas-là, la lecture ligne par ligne est
tout à fait indiquée, pour faciliter aussi le comptage des lignes.
Ca parait très raisonnable.
Mon expérience me ferait croire qu'il n'y aurait pas grand monde pour
lire l'erreur afficher si le traitement n'indique pas une erreur
claire (genre return != 0 dans le main).
Tout à fait. Il faut d'une part écrire un message clair sur std::cerr
qui permet à l'utilisateur de rétrouver l'erreur, et de l'autre,
souvent, terminer le programme avec un code d'erreur, pour que quelqu'un
qui s'en sert dans un script peut arrêter le traitement.
--
James Kanze GABI Software http://www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
std::istringstream s( line ) ; line >> i >> j >> std::ws ;
Je connaissais pas l'utilisation de ws comme ça. Intéressant.
if ( ! line || line.peek() != EOF ) {
Pas sûr du line.peek(), probablement s.peek().
En fait, je me suis servi de line partout où il aurait fallu s :
s >> i >> j >> std::ws ; if ( !s || s.peek() != EOF ) { ... }
Aussi, on pourrait aussi bien utiliser get à la place de peek.
// erreur... }
En fait, si quelque part il y a une ligne qui manque un nombre, si tu ne vérifies pas ligne par ligne, tu ne détectes l'erreur qu'à la fin.
La question fondamentale, c'est qu'est-ce qu'on va faire avec les erreurs qu'on détecte. Mon expérience suggère qu'on va afficher l'erreur. Avec son numéro de ligne, pour que l'utilisateur peut le rétrouver facilement. Dans ce cas-là, la lecture ligne par ligne est tout à fait indiquée, pour faciliter aussi le comptage des lignes.
Ca parait très raisonnable. Mon expérience me ferait croire qu'il n'y aurait pas grand monde pour lire l'erreur afficher si le traitement n'indique pas une erreur claire (genre return != 0 dans le main).
Tout à fait. Il faut d'une part écrire un message clair sur std::cerr qui permet à l'utilisateur de rétrouver l'erreur, et de l'autre, souvent, terminer le programme avec un code d'erreur, pour que quelqu'un qui s'en sert dans un script peut arrêter le traitement.
-- James Kanze GABI Software http://www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
drkm
writes:
C'est vrai que on peut être plus souple avec les fichiers générés par un programme. Et plus rigueureux, aussi -- un programme ne va pas insérer un nombre aléatoire de blancs comme séparateur, par exemple. Une vérification est quand même intéressant
Dans ce cas, j'aurais même tendance à être plus strict, et n'accepter alors qu'un espace, par exemple, au lieu d'une séquence de un ou plusieurs caractères blancs. Afin de détecter le plus de symptômes possibles d'un fichier corrompu, d'une erreur de formatage, d'un bug du programme générateur, etc.
--drkm
kanze@gabi-soft.fr writes:
C'est vrai que on peut être plus souple avec les fichiers générés par un
programme. Et plus rigueureux, aussi -- un programme ne va pas insérer
un nombre aléatoire de blancs comme séparateur, par exemple. Une
vérification est quand même intéressant
Dans ce cas, j'aurais même tendance à être plus strict, et
n'accepter alors qu'un espace, par exemple, au lieu d'une séquence de
un ou plusieurs caractères blancs. Afin de détecter le plus de
symptômes possibles d'un fichier corrompu, d'une erreur de formatage,
d'un bug du programme générateur, etc.
C'est vrai que on peut être plus souple avec les fichiers générés par un programme. Et plus rigueureux, aussi -- un programme ne va pas insérer un nombre aléatoire de blancs comme séparateur, par exemple. Une vérification est quand même intéressant
Dans ce cas, j'aurais même tendance à être plus strict, et n'accepter alors qu'un espace, par exemple, au lieu d'une séquence de un ou plusieurs caractères blancs. Afin de détecter le plus de symptômes possibles d'un fichier corrompu, d'une erreur de formatage, d'un bug du programme générateur, etc.
--drkm
Fabien LE LEZ
On Wed, 13 Oct 2004 22:03:05 +0200, drkm :
Dans ce cas, j'aurais même tendance à être plus strict, et n'accepter alors qu'un espace, par exemple, au lieu d'une séquence de un ou plusieurs caractères blancs.
Ça dépend de ce qu'indiquent les spécifications. Je vois au moins un avantage à autoriser plusieurs blancs : permettre d'aligner les nombres pour faciliter la lecture par un humain.
-- ;-)
On Wed, 13 Oct 2004 22:03:05 +0200, drkm <usenet.fclcxx@fgeorges.org>:
Dans ce cas, j'aurais même tendance à être plus strict, et
n'accepter alors qu'un espace, par exemple, au lieu d'une séquence de
un ou plusieurs caractères blancs.
Ça dépend de ce qu'indiquent les spécifications.
Je vois au moins un avantage à autoriser plusieurs blancs : permettre
d'aligner les nombres pour faciliter la lecture par un humain.
Dans ce cas, j'aurais même tendance à être plus strict, et n'accepter alors qu'un espace, par exemple, au lieu d'une séquence de un ou plusieurs caractères blancs.
Ça dépend de ce qu'indiquent les spécifications. Je vois au moins un avantage à autoriser plusieurs blancs : permettre d'aligner les nombres pour faciliter la lecture par un humain.
-- ;-)
David
Je suppose que tu serais content aussi avec un compilateur C++ qui ne signalait aucune erreur, mais générait simplement du mauvais code si ton programme avait une erreur.
Errare humanae est, comme on dit. Tu ne vas jamais pouvoir attraper toutes les erreurs -- si l'utilisateur a tapé 110, quand il voulait taper 10, et les deux valeurs sont raisonables, il n'y a rien que tu puisses faire. Mais en général, plus on detecte d'erreurs possibles, et plus on les localise, mieux ça vaut. (Tu ne seras probablement pas content avec un compilateur qui affichait simplement "?", et s'arrêtait, dès qu'il trouvait une erreur, non plus.)
Complétement d'accord avec toi. Quand je programme ce genre de traitement, j'essaye d'évaluer le risque et/ou l'intérêt de faire ou ne pas valider le fichier en entrée. Dans le cas présent, je ne vois aucun intérêt de valider le fichier. Pour un fichier aux données plus critiques, c'est évident qu'il faut faire quelque chose.
Remarque que pour le compilateur, ça fait un moment que je me commente juste de lire le numéro de ligne qui coïnce, pour aller dans le code directement pour voir ce qui cloche (il suffit de voir pour la première fois un message d'erreur sur une utilisation hasardeuse de la STL...).
C'est vrai que on peut être plus souple avec les fichiers générés par un programme. Et plus rigueureux, aussi -- un programme ne va pas insérer un nombre aléatoire de blancs comme séparateur, par exemple. Une vérification est quand même intéressant, puisqu'on a pû te donner de mauvais fichier. En revanche, dans ce cas-là, un message simple sans localisation, etc., peut suffire.
Ca me va, même si le simple message est peut être insuffisant. Si un fichier généré automatique est faux, il me faut une explication.
Pas vraiment. fgets marche assez bien. (Évidemment, il faut limiter la longueur des lignes. Mais dans la pratique, ce n'est pas forcement un problème.)
Au vu des codes que j'ai lu, un moment je me suis même demandé si cette fonction existait ;-)
Bon, en tout cas j'essayerai de bien préciser mes choix quand je proposerai un exemple de code dans les news :-)
David.
Je suppose que tu serais content aussi avec un compilateur C++ qui ne
signalait aucune erreur, mais générait simplement du mauvais code si ton
programme avait une erreur.
Errare humanae est, comme on dit. Tu ne vas jamais pouvoir attraper
toutes les erreurs -- si l'utilisateur a tapé 110, quand il voulait
taper 10, et les deux valeurs sont raisonables, il n'y a rien que tu
puisses faire. Mais en général, plus on detecte d'erreurs possibles, et
plus on les localise, mieux ça vaut. (Tu ne seras probablement pas
content avec un compilateur qui affichait simplement "?", et s'arrêtait,
dès qu'il trouvait une erreur, non plus.)
Complétement d'accord avec toi.
Quand je programme ce genre de traitement, j'essaye d'évaluer
le risque et/ou l'intérêt de faire ou ne pas valider le fichier en entrée.
Dans le cas présent, je ne vois aucun intérêt de valider le fichier.
Pour un fichier aux données plus critiques, c'est évident qu'il faut
faire quelque chose.
Remarque que pour le compilateur, ça fait un moment que je me commente
juste de lire le numéro de ligne qui coïnce, pour aller dans le code
directement pour voir ce qui cloche (il suffit de voir pour la première
fois un message d'erreur sur une utilisation hasardeuse de la STL...).
C'est vrai que on peut être plus souple avec les fichiers générés par un
programme. Et plus rigueureux, aussi -- un programme ne va pas insérer
un nombre aléatoire de blancs comme séparateur, par exemple. Une
vérification est quand même intéressant, puisqu'on a pû te donner de
mauvais fichier. En revanche, dans ce cas-là, un message simple sans
localisation, etc., peut suffire.
Ca me va, même si le simple message est peut être
insuffisant. Si un fichier généré automatique est faux, il
me faut une explication.
Pas vraiment. fgets marche assez bien. (Évidemment, il faut limiter la
longueur des lignes. Mais dans la pratique, ce n'est pas forcement un
problème.)
Au vu des codes que j'ai lu, un moment je me suis même demandé si cette
fonction existait ;-)
Bon, en tout cas j'essayerai de bien préciser mes choix quand je proposerai
un exemple de code dans les news :-)
Je suppose que tu serais content aussi avec un compilateur C++ qui ne signalait aucune erreur, mais générait simplement du mauvais code si ton programme avait une erreur.
Errare humanae est, comme on dit. Tu ne vas jamais pouvoir attraper toutes les erreurs -- si l'utilisateur a tapé 110, quand il voulait taper 10, et les deux valeurs sont raisonables, il n'y a rien que tu puisses faire. Mais en général, plus on detecte d'erreurs possibles, et plus on les localise, mieux ça vaut. (Tu ne seras probablement pas content avec un compilateur qui affichait simplement "?", et s'arrêtait, dès qu'il trouvait une erreur, non plus.)
Complétement d'accord avec toi. Quand je programme ce genre de traitement, j'essaye d'évaluer le risque et/ou l'intérêt de faire ou ne pas valider le fichier en entrée. Dans le cas présent, je ne vois aucun intérêt de valider le fichier. Pour un fichier aux données plus critiques, c'est évident qu'il faut faire quelque chose.
Remarque que pour le compilateur, ça fait un moment que je me commente juste de lire le numéro de ligne qui coïnce, pour aller dans le code directement pour voir ce qui cloche (il suffit de voir pour la première fois un message d'erreur sur une utilisation hasardeuse de la STL...).
C'est vrai que on peut être plus souple avec les fichiers générés par un programme. Et plus rigueureux, aussi -- un programme ne va pas insérer un nombre aléatoire de blancs comme séparateur, par exemple. Une vérification est quand même intéressant, puisqu'on a pû te donner de mauvais fichier. En revanche, dans ce cas-là, un message simple sans localisation, etc., peut suffire.
Ca me va, même si le simple message est peut être insuffisant. Si un fichier généré automatique est faux, il me faut une explication.
Pas vraiment. fgets marche assez bien. (Évidemment, il faut limiter la longueur des lignes. Mais dans la pratique, ce n'est pas forcement un problème.)
Au vu des codes que j'ai lu, un moment je me suis même demandé si cette fonction existait ;-)
Bon, en tout cas j'essayerai de bien préciser mes choix quand je proposerai un exemple de code dans les news :-)
David.
drkm
Fabien LE LEZ writes:
On Wed, 13 Oct 2004 22:03:05 +0200, drkm :
Dans ce cas, j'aurais même tendance à être plus strict, et n'accepter alors qu'un espace, par exemple, au lieu d'une séquence de un ou plusieurs caractères blancs.
Ça dépend de ce qu'indiquent les spécifications. Je vois au moins un avantage à autoriser plusieurs blancs : permettre d'aligner les nombres pour faciliter la lecture par un humain.
Bien sûr. J'ai l'impression que c'est d'ailleurs le genre de « liberté » souvent présente dans des formats éditables directement par des humains. Je disais juste que lorsque le format est strictement destiné à être généré par un programme, c'est un genre de fantaisie inutile.
--drkm
Fabien LE LEZ <gramster@gramster.com> writes:
On Wed, 13 Oct 2004 22:03:05 +0200, drkm <usenet.fclcxx@fgeorges.org>:
Dans ce cas, j'aurais même tendance à être plus strict, et
n'accepter alors qu'un espace, par exemple, au lieu d'une séquence de
un ou plusieurs caractères blancs.
Ça dépend de ce qu'indiquent les spécifications.
Je vois au moins un avantage à autoriser plusieurs blancs : permettre
d'aligner les nombres pour faciliter la lecture par un humain.
Bien sûr. J'ai l'impression que c'est d'ailleurs le genre de
« liberté » souvent présente dans des formats éditables directement
par des humains. Je disais juste que lorsque le format est
strictement destiné à être généré par un programme, c'est un genre de
fantaisie inutile.
Dans ce cas, j'aurais même tendance à être plus strict, et n'accepter alors qu'un espace, par exemple, au lieu d'une séquence de un ou plusieurs caractères blancs.
Ça dépend de ce qu'indiquent les spécifications. Je vois au moins un avantage à autoriser plusieurs blancs : permettre d'aligner les nombres pour faciliter la lecture par un humain.
Bien sûr. J'ai l'impression que c'est d'ailleurs le genre de « liberté » souvent présente dans des formats éditables directement par des humains. Je disais juste que lorsque le format est strictement destiné à être généré par un programme, c'est un genre de fantaisie inutile.
--drkm
drkm
David writes:
Dans le cas présent, je ne vois aucun intérêt de valider le fichier.
Mais il me semble que l'on ne sait pas grand-chose du contexte d'utilisation du fichier d'entrée, ni même de son format. Je pense que dans ce genre de choses, le défaut serait de toujours vérifier. Mais si l'on a des raisons permettant d'éviter ces vérifications, bien sûr, on peut s'en passer.
--drkm
David <dfleury2@libertysurf.fr> writes:
Dans le cas présent, je ne vois aucun intérêt de valider le fichier.
Mais il me semble que l'on ne sait pas grand-chose du contexte
d'utilisation du fichier d'entrée, ni même de son format. Je pense
que dans ce genre de choses, le défaut serait de toujours vérifier.
Mais si l'on a des raisons permettant d'éviter ces vérifications, bien
sûr, on peut s'en passer.
Dans le cas présent, je ne vois aucun intérêt de valider le fichier.
Mais il me semble que l'on ne sait pas grand-chose du contexte d'utilisation du fichier d'entrée, ni même de son format. Je pense que dans ce genre de choses, le défaut serait de toujours vérifier. Mais si l'on a des raisons permettant d'éviter ces vérifications, bien sûr, on peut s'en passer.
--drkm
Loïc Joly
drkm wrote:
David writes:
Dans le cas présent, je ne vois aucun intérêt de valider le fichier.
Mais il me semble que l'on ne sait pas grand-chose du contexte d'utilisation du fichier d'entrée, ni même de son format.
Hum, deux colonnes de chiffre... Coordonnées... Ca y est, c'est une liste de cible pour des missiles nucléaires ! Bon, je pense que ce n'est pas si grave de ne pas valider les données par tous les moyens possible. ;p
-- Loïc
drkm wrote:
David <dfleury2@libertysurf.fr> writes:
Dans le cas présent, je ne vois aucun intérêt de valider le fichier.
Mais il me semble que l'on ne sait pas grand-chose du contexte
d'utilisation du fichier d'entrée, ni même de son format.
Hum, deux colonnes de chiffre... Coordonnées... Ca y est, c'est une
liste de cible pour des missiles nucléaires ! Bon, je pense que ce n'est
pas si grave de ne pas valider les données par tous les moyens possible. ;p
Dans le cas présent, je ne vois aucun intérêt de valider le fichier.
Mais il me semble que l'on ne sait pas grand-chose du contexte d'utilisation du fichier d'entrée, ni même de son format.
Hum, deux colonnes de chiffre... Coordonnées... Ca y est, c'est une liste de cible pour des missiles nucléaires ! Bon, je pense que ce n'est pas si grave de ne pas valider les données par tous les moyens possible. ;p
-- Loïc
Arnaud Meurgues
David wrote:
Remarque que pour le compilateur, ça fait un moment que je me commente juste de lire le numéro de ligne qui coïnce, pour aller dans le code directement pour voir ce qui cloche (il suffit de voir pour la première fois un message d'erreur sur une utilisation hasardeuse de la STL...).
Les compilateurs commencent à faire des progrès dans ce domaine. Les messages d'erreur sur les templates de msvc7 sont beaucoup plus lisibles que ceux que pouvaient produire msvc6, par exemple.
-- Arnaud (Supprimez les geneurs pour me répondre)
David wrote:
Remarque que pour le compilateur, ça fait un moment que je me commente
juste de lire le numéro de ligne qui coïnce, pour aller dans le code
directement pour voir ce qui cloche (il suffit de voir pour la première
fois un message d'erreur sur une utilisation hasardeuse de la STL...).
Les compilateurs commencent à faire des progrès dans ce domaine. Les
messages d'erreur sur les templates de msvc7 sont beaucoup plus lisibles
que ceux que pouvaient produire msvc6, par exemple.
--
Arnaud
(Supprimez les geneurs pour me répondre)
Remarque que pour le compilateur, ça fait un moment que je me commente juste de lire le numéro de ligne qui coïnce, pour aller dans le code directement pour voir ce qui cloche (il suffit de voir pour la première fois un message d'erreur sur une utilisation hasardeuse de la STL...).
Les compilateurs commencent à faire des progrès dans ce domaine. Les messages d'erreur sur les templates de msvc7 sont beaucoup plus lisibles que ceux que pouvaient produire msvc6, par exemple.
-- Arnaud (Supprimez les geneurs pour me répondre)
Christophe Lephay
David wrote:
Sur cet exemple, je n'ai pas eu un exemple de buffer overflow.
La possibilité d'exploiter un buffer overflow ne dépend pas de quelques lignes de code mais de l'environnement complet. L'environnement en question englobe tant le système d'exploitation que le reste du programme. La non-vérification des données en entrée ne garantit pas un buffer overflow mais ne garantit pas non plus qu'il est rendu possible. Le seul moyen de garantir qu'il ne sera pas possible consiste à tester la validité. La notion de garantie est la clé essentielle dans la mise en oeuvre de systèmes complexes.
Il n'y a pas de règle précise sur ce que doit garantir chaque fonction. Le minimum à l'heure actuelle me semble consister à indiquer, de préférence d'une manière qu'il ne pourra ignorer (exceptions, assert, etc), au code appelant que les données sont invalides (je ne parle pas des données en entrées, qui ne devraient pas être connues dans le code appelant la fonction chargée de les lire). De ce point de vue, strcpy n'est pas un modèle du genre et n'est probablement pas un bon exemple de ce qu'il convient de faire de manière générale.
Ce dont on peut débattre, c'est de l'utilité de vérifier les données en entrée dans un petit exercice scolaire.
Chris
David wrote:
Sur cet exemple, je n'ai pas eu un exemple de buffer overflow.
La possibilité d'exploiter un buffer overflow ne dépend pas de quelques
lignes de code mais de l'environnement complet. L'environnement en question
englobe tant le système d'exploitation que le reste du programme. La
non-vérification des données en entrée ne garantit pas un buffer overflow
mais ne garantit pas non plus qu'il est rendu possible. Le seul moyen de
garantir qu'il ne sera pas possible consiste à tester la validité. La notion
de garantie est la clé essentielle dans la mise en oeuvre de systèmes
complexes.
Il n'y a pas de règle précise sur ce que doit garantir chaque fonction. Le
minimum à l'heure actuelle me semble consister à indiquer, de préférence
d'une manière qu'il ne pourra ignorer (exceptions, assert, etc), au code
appelant que les données sont invalides (je ne parle pas des données en
entrées, qui ne devraient pas être connues dans le code appelant la fonction
chargée de les lire). De ce point de vue, strcpy n'est pas un modèle du
genre et n'est probablement pas un bon exemple de ce qu'il convient de faire
de manière générale.
Ce dont on peut débattre, c'est de l'utilité de vérifier les données en
entrée dans un petit exercice scolaire.
Sur cet exemple, je n'ai pas eu un exemple de buffer overflow.
La possibilité d'exploiter un buffer overflow ne dépend pas de quelques lignes de code mais de l'environnement complet. L'environnement en question englobe tant le système d'exploitation que le reste du programme. La non-vérification des données en entrée ne garantit pas un buffer overflow mais ne garantit pas non plus qu'il est rendu possible. Le seul moyen de garantir qu'il ne sera pas possible consiste à tester la validité. La notion de garantie est la clé essentielle dans la mise en oeuvre de systèmes complexes.
Il n'y a pas de règle précise sur ce que doit garantir chaque fonction. Le minimum à l'heure actuelle me semble consister à indiquer, de préférence d'une manière qu'il ne pourra ignorer (exceptions, assert, etc), au code appelant que les données sont invalides (je ne parle pas des données en entrées, qui ne devraient pas être connues dans le code appelant la fonction chargée de les lire). De ce point de vue, strcpy n'est pas un modèle du genre et n'est probablement pas un bon exemple de ce qu'il convient de faire de manière générale.
Ce dont on peut débattre, c'est de l'utilité de vérifier les données en entrée dans un petit exercice scolaire.
Chris
drkm
"Christophe Lephay" writes:
Ce dont on peut débattre, c'est de l'utilité de vérifier les données en entrée dans un petit exercice scolaire.
L'utilité étant de prendre de bonnes habitudes. Apprendre à, et comment, vérifier les données.
Comment un étudiant penserait-il à faire ces vérifications si tout le code qu'on lui fait pondre ne le vérifie pas ? Et pire, si lorsqu'il les vérifie, se voit répondre que ça ne sert à rien, que ce n'est pas le but de l'exo (situation vécue) !
Ce dont on peut débattre, c'est de l'utilité de vérifier les données en
entrée dans un petit exercice scolaire.
L'utilité étant de prendre de bonnes habitudes. Apprendre à, et
comment, vérifier les données.
Comment un étudiant penserait-il à faire ces vérifications si tout
le code qu'on lui fait pondre ne le vérifie pas ? Et pire, si
lorsqu'il les vérifie, se voit répondre que ça ne sert à rien, que ce
n'est pas le but de l'exo (situation vécue) !
Ce dont on peut débattre, c'est de l'utilité de vérifier les données en entrée dans un petit exercice scolaire.
L'utilité étant de prendre de bonnes habitudes. Apprendre à, et comment, vérifier les données.
Comment un étudiant penserait-il à faire ces vérifications si tout le code qu'on lui fait pondre ne le vérifie pas ? Et pire, si lorsqu'il les vérifie, se voit répondre que ça ne sert à rien, que ce n'est pas le but de l'exo (situation vécue) !
