Entrees formatees

Marc Boyer, le 07/09/2009 a écrit :

[...]

Oui, mais quelles autres solutions pour lire des entrées en C avec
des débutants ?

Il me semble que après les paramètres en dur dans le code, on pourrait
embrayer sur la prise de paramètres dans la ligne de commandes. Sous la
forme:

int main(int argc, char* argv[]){}

sachant que le fait qu'une chaîne est un char*, ainsi que la
présentation de main(), doivent venir *très* tôt dans le cursus.

On apprendra très vite à écrire et utiliser un usage(), et à analyser
la ligne de commande, ce qui n'est pas très compliqué. On pourra même
évoquer l'ensemble plus ou moins monolithique constitué par le cahier
des charges ou scope of work, la ligne de commande, usage(), -help et
la nécessité d'écrire immédiatement la documentation, page de man ou
autre.

Ensuite, et rapidement également, on apprendra à traiter une entrée de
type Yes/No, ou Proceed/Abort, ou Proceed/Modify/Abort de façon
réaliste.

D'une part on entre bien plus naturellement qu'avec scanf() dans un
parcours d'apprentissage à peu près linéaire - bon, ce ne sera pas tout
à fait possible, mais ce sera mieux - mais on collera mieux à la
réalité. Je m'explique: si j'inventorie les outils en console que
j'utilise couramment, qu'est ce que je trouve dans une grande majorité
des cas ? Une ligne de commande assez touffue, avec un man parfois
épais, quelques affichages de type "synthèse" suivis d'une demande de
confirmation. Dans un certain nombre de cas, j'ai de véritables entrées
à renseigner, mais il est clair que les programmeurs ont tout fait pour
que ces entrées puissent être un affichage suivi d'un choix 1 parmi n.
C'est d'ailleurs ce que je cherche à faire quand j'écris des outils
console, même dans d'autres langages que le C moins sauvages au niveau
des E/S humaines.

Dans ces conditions, les entrées scanf() deviendraient une spécialité,
un chapitre à part, au même titre que le calcul flottant par exemple.

--
Pierre Maurette

Le 07-09-2009, Pierre Maurette <maurettepierre@wanadoo.fr> a écrit :

Marc Boyer, le 07/09/2009 a écrit :
[...]

Oui, mais quelles autres solutions pour lire des entrées en C avec
des débutants ?

Il me semble que après les paramètres en dur dans le code, on pourrait
embrayer sur la prise de paramètres dans la ligne de commandes. Sous la
forme:

int main(int argc, char* argv[]){}

sachant que le fait qu'une chaîne est un char*, ainsi que la
présentation de main(), doivent venir *très* tôt dans le cursus.

Déjà, le tableau de pointeur de char, ça va être dur à faire
avaller en début de cursus (pas avant une dizaine de TP quand même).

Ensuite, on prend quoi pour lire un entier ou un flottant ?
atoi ? strtol avec son char** ?

On apprendra très vite à écrire et utiliser un usage(), et à analyser
la ligne de commande, ce qui n'est pas très compliqué.

Heuh. On ne doit pas parler des mêmes étudiants.

On pourra même
évoquer l'ensemble plus ou moins monolithique constitué par le cahier
des charges ou scope of work, la ligne de commande, usage(), -help et
la nécessité d'écrire immédiatement la documentation, page de man ou
autre.

Le prof évoque, la caravane passe...

D'une part on entre bien plus naturellement qu'avec scanf() dans un
parcours d'apprentissage à peu près linéaire - bon, ce ne sera pas tout
à fait possible, mais ce sera mieux - mais on collera mieux à la
réalité.

Parce que tu penses que les 30 premières heures de C doivent se
faire avec des outils de pros ?

Je m'explique: si j'inventorie les outils en console que
j'utilise couramment, qu'est ce que je trouve dans une grande majorité
des cas ? Une ligne de commande assez touffue, avec un man parfois
épais, quelques affichages de type "synthèse" suivis d'une demande de
confirmation. Dans un certain nombre de cas, j'ai de véritables entrées
à renseigner, mais il est clair que les programmeurs ont tout fait pour
que ces entrées puissent être un affichage suivi d'un choix 1 parmi n.
C'est d'ailleurs ce que je cherche à faire quand j'écris des outils
console, même dans d'autres langages que le C moins sauvages au niveau
des E/S humaines.

Et oui, les saisies plus complexes sont réalisées avec une IHM
de type "fenêtre".

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0

Marc Boyer a écrit :

Le 04-09-2009, candide <candide@free.invalid> a écrit :

Le problème, c'est qu'une maîtrise fiable des entrées est un problème
difficile par nature. D'une autre côté, d'un point de vue pédagogique
il est préférable de pouvoir faire quelques entrées/sorties dans les
exos.

Des sorties, c'est obligatoire. Les entrées, c'est du marketing, de la pseudo
interactivité, de la comm, bref appelle ça comme tu veux (quand on apprend le
_langage_, sinon c'est évidemment essentiel). Enfin, bon, c'est juste mon avis.

Ah ? Franchement, nous nous étions posé la question des E/S sur
notre programme de langage C et la question de faire des programmes
sans entrées avait été évoquée, et vite rejettée...

et pourquoi ?

Oui, mais quelles autres solutions pour lire des entrées en C avec
des débutants ?

Pour apprendre le langage, pas besoin d'entrées, au contraire, ça ralentit car
pose plein de questions hors langage et plein de question utilisant le langage
et dont on maitrise pas le contenu.

Bien sûr qu'un cours de C doit parler des E/S mais tout à la fin et de façon
choisie pour être utile dans les cas les plus courants. J'ai beaucoup souffert
en lisant le K&R, c'est selon moi un très très mauvais ouvrage d'apprentissage
mais il a un certain nombre de qualités dont celle (je pense ici involontaire
!!) de ne pas donner une ligne de code appelant scanf() avant le chapitre 7,
celui qui traite des E/S. Je dis involontaire car le principe (implicite) de
base du K&R est que le livre se lit comme un roman, que l'apprentissage du
langage est purement intellectuel et donc qu'on n'a même pas besoin d'une
machine (en plus à l'époque -- 1988 mais en fait les années soixante-dix, années
de sorties de la première édition, -- ce n'était pas aussi répandu que
maintenant, rien à voir même).

Marc Boyer a écrit :

Déjà, le tableau de pointeur de char, ça va être dur à faire
avaller en début de cursus (pas avant une dizaine de TP quand même).

J'ai eu _exactement_ la même pensée en lisant ce qu'écrivait Pierre Maurette et
pareil pour toute la suite de son message. Problème rédhibitoire d'empathie.

Le 07-09-2009, candide <candide@free.invalid> a écrit :

Marc Boyer a écrit :

Le 04-09-2009, candide <candide@free.invalid> a écrit :

Le problème, c'est qu'une maîtrise fiable des entrées est un problème
difficile par nature. D'une autre côté, d'un point de vue pédagogique
il est préférable de pouvoir faire quelques entrées/sorties dans les
exos.

Des sorties, c'est obligatoire. Les entrées, c'est du marketing, de la pseudo
interactivité, de la comm, bref appelle ça comme tu veux (quand on apprend le
langage, sinon c'est évidemment essentiel). Enfin, bon, c'est juste mon avis.

Ca donne un aspect "ludique". Tu peux regretter que cela soit nécessaire
dans les enseignement, mais ça aide.

Ah ? Franchement, nous nous étions posé la question des E/S sur
notre programme de langage C et la question de faire des programmes
sans entrées avait été évoquée, et vite rejettée...

et pourquoi ?

Parce que nous étions incapables de batir un programme d'une dizaine
de TD et TP sans faire quelques entrées.

Oui, mais quelles autres solutions pour lire des entrées en C avec
des débutants ?

Pour apprendre le langage, pas besoin d'entrées, au contraire, ça ralentit car
pose plein de questions hors langage et plein de question utilisant le langage
et dont on maitrise pas le contenu.

Je ne sais qui est "on". Mes anciens étudiants acceptaient tout
à fait d'utiliser un scanf("%d",&i) sans trop se poser de questions
sur "mais qu'est-ce qui se passerait avec scanf("Solde ? %6d",&i)".

Bien sûr qu'un cours de C doit parler des E/S mais tout à la fin et de façon
choisie pour être utile dans les cas les plus courants. J'ai beaucoup souffert
en lisant le K&R, c'est selon moi un très très mauvais ouvrage d'apprentissage

Je partage cet avis (encore que "très mauvais" me semble exagéré) sur le K&R.
Après, arriver à batir un cursus sans aborder les E/S dans les 30 premières
heures, j'aurais du mal à faire.
Nous avons préféré en fait attaquer les E/S très vite.

mais il a un certain nombre de qualités dont celle (je pense ici involontaire
!!) de ne pas donner une ligne de code appelant scanf() avant le chapitre 7,
celui qui traite des E/S.

Non, je pense que c'est volontaire, mais ça reste une interprétation
de ma part.

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0

candide scripsit:

Des sorties, c'est obligatoire. Les entrées, c'est du marketing, de la
pseudo interactivité, de la comm, bref appelle ça comme tu veux (quand
on apprend le _langage_, sinon c'est évidemment essentiel). Enfin,
bon, c'est juste mon avis.

D'une part, comme l'a dit Marc, une part d'interactivité est
relativement indispensable d'un point de vue pédagogique (et je ne
trouve pas ça regrettable : au contraire, c'est un avantage de la
programmation part rapport à d'autres disciplines (au hasard, les maths)
qu'on puisse y introduire une part d'interactivité de façon pas trop
artificielles).

D'autre part, je me demande quel sens ça a de vouloir dissocier, comme
tu semble vouloir le faire, l'apprentissage du langage et celui de
points aussi essentiels que la gestion propre des E/S dans ce langage.
Je suis assez inquiet à l'idée que des personnes n'ayant étudier que
« le langage lui-même » se croient capables de coder des vrais
programmes pour la vraie vie (incluant des E/S, donc) et finissent par
pondre du code plein d'erreurs potentiellement dangereuses à ce niveau.
(Toute ressemblance avec des faits réels...) Du coup même si ça ne
facilite pas les choses (mais qui a dit qu'apprendre le C était
facile ?) ça peut avoir sacrément du sens d'introduire des E/S assez
tôt, au moins pour avoir essayer de faire prendre conscience au
étudiants que c'est un sujet délicat.

--
Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/

Marc Boyer a écrit :

Ca donne un aspect "ludique". Tu peux regretter que cela soit nécessaire
dans les enseignement, mais ça aide.

"ludique", je me demandais si le mot allait être prononcé. Et bien sache que
pour moi, le C est essentiellement ludique, qu'il s'agisse de faire des
programmes en console ou des petit jeux avec un lib graphique.

Il y a plein de façon d'être ludique sans faire des entrées.

Très franchement, c'est une illusion, je connais très peu de programmes C
d'apprentissage où les entrées vont apporter un vrai plus ludique indispensable.
Le problème est que le programme au bout du compte n'est jamais assez ludique ce
qui conduit à une surenchère dans la recherche d'une sophistication des entrées
[voire à une dérive complète où toutes les entrées sont saisies au clavier par
l'utilisateur, le forum du siteduzero est full de codes comme ça, au bout du
compte les mecs passent leur temps à déboguer des entrées et n'apprennent rien].
En situation de début d'apprentissage et même à un stade plus avancé, l'étudiant
n'a pas les moyens de faire des entrées sécurisées.

Les entrées, je ne suis pas contre mais à condition qu'elles soient vraiment
très surveillées et contrôlés, tout ça pour donner priorité au langage
proprement dit.

Parce que nous étions incapables de batir un programme d'une dizaine
de TD et TP sans faire quelques entrées.

Tu fais tes entrées en dur dans le code. Comme c'est des programmes
d'apprentissage, t'es sans cesse en train de reprendre ton source et si tu veux
changer des données et bien tu les changes dans le source et tu recompiles.

Je ne sais qui est "on". Mes anciens étudiants acceptaient tout
à fait d'utiliser un scanf("%d",&i) sans trop se poser de questions
sur "mais qu'est-ce qui se passerait avec scanf("Solde ? %6d",&i)".

Mais rapidement on tombe sur des questions naturelles comme saisir une chaîne
contenant des espaces avec scanf() et c'est le début de la surenchère (ou des
frustrations). Si c'est pour se limiter _strictement_
à une saisie très occasionnelle d'un nombre, d'un caractère ou d'une chaîne
toute simple ok mais alors dans ce cas, on peut facilement se passer de les
saisir au clavier.

Manuel Pégourié-Gonnard a écrit :

D'une part, comme l'a dit Marc, une part d'interactivité est
relativement indispensable d'un point de vue pédagogique (et je ne

"relativement indispensable", c'est pas contradictoire ?

trouve pas ça regrettable : au contraire, c'est un avantage de la
programmation part rapport à d'autres disciplines (au hasard, les maths)
qu'on puisse y introduire une part d'interactivité de façon pas trop
artificielles).

Je suis d'accord, je me rappelle l'effet que m'a fait mon premier scanf, j'avais
trouvé ça magique. Mais faut savoir en sortir surtout que ça devient de
l'interactivité avec soi-même ...

Sinon, c'est quoi tes exemples d'interactivité pas trop artificielle, au niveau
débutant et même débutant avancé ? Il ne faudrait pas confondre la cerise et le
gâteau.

D'autre part, je me demande quel sens ça a de vouloir dissocier, comme
tu semble vouloir le faire, l'apprentissage du langage et celui de
points aussi essentiels que la gestion propre des E/S dans ce langage.

Mais je n'y suis pour rien, la Norme elle même distingue bien les deux choses :
la bibliothèque standard (clause 6 je crois ) ne fait pas partie du langage
(clause suivante). La dissociation vient simplement du fait que ce que je
considère l'objectif premier est d'apprendre le langage (structures de contrôle,
types, opérateurs, etc). Si tu fais ça couplé avec des E/S, tu effectues une
surcharge d'apprentissage :

1°) ça t'oblige à apprendre ou connaître ou maîtriser suffisamment une notion
qui n'a aucun rapport avec ton objectif premier (par exemple, apprendre les
boucles, ou l'aiguillage switch, etc)

2°) ça t'oblige le plus souvent à connaître déjà le langage de manière non
élémentaire(songe par exemple que scanf() suppose de plus ou moins savoir ce
qu'est une adresse, ça peut conduire à des idées fausses genre "il faut toujours
que le 2ème argument du scanf() commence par le signe &") ce qui est
contradictoire avec l'objectif initial.

Sans compter les effet pervers où on ne sait plus ce que fait telle ou telle
fonction : calcule-t-elle, capture-t-elle ou affiche-t-elle ?


Je suis souvent étonné que les informaticiens ne mettent pas en pratique dans
leur enseignement des principes qui guident le génie logiciel, comme le faible
couplage, c'est bien ce que je défends ici.

Je suis assez inquiet à l'idée que des personnes n'ayant étudier que

"inquiet", comme tu y vas

« le langage lui-même » se croient capables de coder des vrais
programmes pour la vraie vie (incluant des E/S, donc) et finissent par
pondre du code plein d'erreurs potentiellement dangereuses à ce niveau.

Je ne sais pas si ce propos s'adresse à moi nominalement. En ce qui me concerne,
j'utiliserais les E/S en proportion de ce je connais d'elles.

Par ailleurs, je ne dis pas qu'un programmeur accompli doive ignorer les E/S, je
dis que chaque chose en son temps et qu'on apprend en fonction des besoins. Je
veux juste éliminer des causes de ralentissement d'apprentissage du langage (la
question des E/S n'est qu'une des nombreuses causes).

Et sinon, tu peux coder de vrais programmes plus ou moins complexes (des
algorithmes par exemple, regarde un md5 par exemple, un solveur de sudoku, un
"compte est bon", etc) sans presque jamais #inclure <stdio.h>. Les
entrées/sorties, c'est fondamentalement une affaire d'interfaçage et donc ça
peut se traiter à part.

(Toute ressemblance avec des faits réels...) Du coup même si ça ne
facilite pas les choses (mais qui a dit qu'apprendre le C était
facile ?) ça peut avoir sacrément du sens d'introduire des E/S assez
tôt, au moins pour avoir essayer de faire prendre conscience au
étudiants que c'est un sujet délicat.

Ça ne me paraît pas du tout être une priorité, surtout si on a 30 heures comme
le disait Marc. Et de toute façon, les E/S c'est intrinsèquement délicat, c'est
pas vraiment le C qui est en cause. Les entrées/sorties, c'est de la comm, je
dis pas que ça compte pas, surtout quand on est sur un forum ;) , mais faut-il
encore avoir quelque chose à dire (donc les E/S, ça vient après).

Mais un peu dans l'idée de ce qu'a dit Antoine précédemment, les E/S par leur
complexité, permettent aussi lorsqu'on les étudie de progresser dans
l'apprentissage du langage de la même façon que lorsque tu étudies la poétique
française, tu finis par améliorer ta connaissance de la langue.

candide scripsit:

Manuel Pégourié-Gonnard a écrit :

D'une part, comme l'a dit Marc, une part d'interactivité est
relativement indispensable d'un point de vue pédagogique (et je ne

"relativement indispensable", c'est pas contradictoire ?

Disons que c'est souvent indispensable pour aider les étudiants à
« accrocher », mais que dans l'absolu je connais des gens que ça ne
dérange pas du tout de donner des cours où rien n'aide les étudiants à
accrocher.

La dissociation vient simplement du fait que ce que je considère
l'objectif premier est d'apprendre le langage (structures de contrôle,
types, opérateurs, etc).

Si c'est « premier » dans le sens ordinal (l'étape initiale, qui sera suivie
d'autres étapes), pourquoi pas. Si c'est « premier » dans le sens
« principal », j'avoue que je suis sceptique sur l'intérêt de la chose.

Si tu fais ça couplé avec des E/S, tu effectues une
surcharge d'apprentissage :

Oui, d'accord sur la surcharge. En même temps, selon le contexte,
certains étudiants peuvent être plus motivés par un sujet si on ne
cherche pas à leur en cacher la complexité, mais qu'on la leur présente
en les aidant à l'apréhender.

Sans compter les effet pervers où on ne sait plus ce que fait telle ou
telle fonction : calcule-t-elle, capture-t-elle ou affiche-t-elle ?

Bah justement, je ne vois pas comment apprendre à dissocier les trois
aspects si on fait exprès d'évacuer les deux derniers (ou au moins le
deuxième). Si on structure mal son code, on le structurera mal aussi
sans E/S.

Je suis assez inquiet à l'idée que des personnes n'ayant étudier que

"inquiet", comme tu y vas

Bah oui, quand je pense au nombre de trous de sécus qu'il y a sans doute
dans du code tournant sur des machines à moi où que j'utilise à un titre
où un autre, dont un certain nombre sont causés par une mauvaise
connaissance de certains pièges, pourtant classiques, du langage C par
le programmeur, j'avoue que ça me rassure pas plus que ça.

« le langage lui-même » se croient capables de coder des vrais
programmes pour la vraie vie (incluant des E/S, donc) et finissent par
pondre du code plein d'erreurs potentiellement dangereuses à ce niveau.

Je ne sais pas si ce propos s'adresse à moi nominalement. En ce qui me
concerne, j'utiliserais les E/S en proportion de ce je connais
d'elles.

Le propos n'était adressé à personne ici en particulier.

Mais un peu dans l'idée de ce qu'a dit Antoine précédemment, les E/S
par leur complexité, permettent aussi lorsqu'on les étudie de
progresser dans l'apprentissage du langage de la même façon que
lorsque tu étudies la poétique française, tu finis par améliorer ta
connaissance de la langue.

Voilà. C'est sans doute une question de tempérament, mais quand
j'apprends un truc, je suis plus motivé pour m'attaquer à des problèmes
difficiles mais intéressants, quitte à apprendre le reste « par effet de
bord », qu'à des problèmes trop aseptisés. Comme il est difficile quand
on enseigne de ne pas penser à ce qu'on aurait aimé suivre soi-même
comme étudiant, j'ai du coup tendance à bien aimer cette méthode
d'enseignement.

Dans mon expérience d'enseignant (relativement courte par rapport à
d'autres intervenants, je n'en doute pas, et d'ailleurs pas en
informatique), j'ai assez rapidement eu l'impression que plus on « en
demande » aux étudiants, plus ils progressent vite. Peut-être que j'ai
eu la chance de n'enseigner que dans des conditions particulièrement
favorables...

--
Manuel Pégourié-Gonnard Institut de mathématiques de Jussieu
http://weblog.elzevir.fr/ http://people.math.jussieu.fr/~mpg/

Le 07-09-2009, candide <candide@free.invalid> a écrit :

Marc Boyer a écrit :

Ca donne un aspect "ludique". Tu peux regretter que cela soit nécessaire
dans les enseignement, mais ça aide.

"ludique", je me demandais si le mot allait être prononcé. Et bien sache que
pour moi, le C est essentiellement ludique, qu'il s'agisse de faire des
programmes en console ou des petit jeux avec un lib graphique.

Oui, mais je ne te considère pas comme représentatif d'une population
d'étudiants.
Dans une promo d'étudiants en informatique, il y à 5-10% d'étudiants
motivés par l'informatique, qui te ressemblent un peu il me semble,
Et 90% d'étudiants qu'il faut motiver, entre carotte et baton,
séduction, jeu, mise en perspective et rappel à l'ordre.

Il y a plein de façon d'être ludique sans faire des entrées.

Très franchement, c'est une illusion, je connais très peu de programmes C
d'apprentissage où les entrées vont apporter un vrai plus ludique
indispensable.

Rien n'est jamais indispensable, c'est une combinaison globale, qui
de plus doit s'adapter à des publics variés.

Le problème est que le programme au bout du compte n'est jamais assez
ludique ce qui conduit à une surenchère dans la recherche d'une
sophistication des entrées [voire à une dérive complète où toutes les
entrées sont saisies au clavier par l'utilisateur, le forum du
siteduzero est full de codes comme ça, au bout du
compte les mecs passent leur temps à déboguer des entrées et
n'apprennent rien].

Peut-être dans le cadre d'auto-formation. Je ne me suis jamais
essayé à cet exercice.
Je ne connais que le cadre de formations enseignées, avec un
programme imposé et des enseignants présents pour recadrer et répondre
aux questions.

En situation de début d'apprentissage et même à un stade plus avancé, l'étudiant
n'a pas les moyens de faire des entrées sécurisées.

Tout à fait.

Les entrées, je ne suis pas contre mais à condition qu'elles soient vraiment
très surveillées et contrôlés, tout ça pour donner priorité au langage
proprement dit.

Chez nous, le niveau d'exigence montait peu à peu. Au début, on fait comme
si l'utilisateur respectait les formats demandés, ensuite, on sensibilise
au problème, puis au final, la robustesse du code à des entrées invalides
est un critère de notation.

Parce que nous étions incapables de batir un programme d'une dizaine
de TD et TP sans faire quelques entrées.

Tu fais tes entrées en dur dans le code. Comme c'est des programmes
d'apprentissage, t'es sans cesse en train de reprendre ton source et si tu veux
changer des données et bien tu les changes dans le source et tu recompiles.

Sauf que l'expérience montre qu'ils ne le font pas. Ils testent leur
code avec un jeu d'entrée, et c'est tout.
De plus, le fait que les entrées soient externes au programme à des
impacts algorithmique: on ne sait pas combien d'itération de boucle
il va falloir faire par exemple.

Je ne sais qui est "on". Mes anciens étudiants acceptaient tout
à fait d'utiliser un scanf("%d",&i) sans trop se poser de questions
sur "mais qu'est-ce qui se passerait avec scanf("Solde ? %6d",&i)".

Mais rapidement on tombe sur des questions naturelles comme saisir une chaîne
contenant des espaces avec scanf() et c'est le début de la surenchère (ou des
frustrations).

Je ne présentais pas le format %s pour scanf ;-)

Si c'est pour se limiter _strictement_
à une saisie très occasionnelle d'un nombre, d'un caractère ou d'une chaîne
toute simple ok mais alors dans ce cas, on peut facilement se passer de les
saisir au clavier.

Non, c'est pour saisir des séries de nombres le plus souvent.
Ou des chaines de caractères simples.

Ceci dit, plus je discute avec toi, plus je me dis que l'expérience
mériterait d'être réfléchie en rebatissant un programme.
Ma seule rétissance, c'est qu'en incluant le test dans le code,
l'étudiant est tenté de se simplifier la vie (par exemple en donnant
le nombre d'entrée, donc en transformant une boucle do/while en for),
et que pour beaucoup d'exercices de boucles (type moyenne, min), cela
impose de traiter les tableaux.

Mais bon, je n'enseigne plus le C.

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0