éternel débutant en C pour mon plaisir, je me permets de venir vous
demander quelques éclaircissements sur une situation que je n'arrive pas
à comprendre :
J'utilise le cours en ligne spécial "grand débutant" du "site du zéro" :
<http://www.siteduzero.com/tutoriel-3-14189-apprenez-a-programmer-en-c.html>
Je réalise les exercices du cours dans deux environnements différents :
- sous windows vista avec l'IDE visual C++ 2008 express
- sous linux ubuntu 9.04 avec gcc
J'ai écrit un programme dans le cadre des exercices proposés sur les
tableaux par ce cours en ligne. Le fichier en question peut être
téléchargé ici :
< http://dl.free.fr/to7PFReLM/tableau.c>
Ce qui m'étonne, c'est que j'arrive à compiler sans difficulté ce code
sous Linux, et que le programme se comporte exactement comme je le
souhaite. Par contre, sous Windows, impossible de compiler, l'IDE me
renvoie 42 erreurs et 31 avertissements !!! La plupart des erreurs
semblent être liées aux variables. Par exemple :
"erreur de syntaxe : absence de ';' avant 'type'"
"identificateur non déclaré"
Or, j'ai beau lire et relire mon code, les variables me sembles toutes
déclarées correctement et il ne manque à mon sens pas de ";" en fin
d'instructions. De plus, comme je le disais au début, le même code se
compile sans aucune erreur sous Linux ...
Alors, comment expliquer que deux compilateurs réagissent aussi
différemment, et où et mon erreur ?
Merci par avance du temps que vous pourrez me consacrer,
Je ne pense pas que ce soit vrai: on apprécise toujours de pouvoir faire des liens entre connaissances, et ces liens (sous réserve qu'ils soient vrais), confortent les apprentissage.
Question d'équilibre car il y a un risque de surcharge. Mon principe d'enseignement favori : le rasoir d'Occam.
Mais il est tout à fait possible de s'en passer.
Oui, je l'ai fait.
La mémoire est une abstraction et elle peut rester telle quand on enseigne le C.
Mais il faut présenter cette abstration, l'enseigner.
Oui, et c'est un manque certain dans les cours de C, in vivo ou imprimés, pardon pour les collègues.
Pas besoin d'aller bien loin. Tiens, retourner un pointeur sur une variable locale de fonction, et manipuler cette valeur...
Il me semble que ce n'est pas le plus courant que l'on rencontre. D'ailleurs, je trouve que le mot "variable" est très trompeur. Le cas que j'ai en mémoire (!) est le suivant :
int *remplirMal(int n) { int t[100] = { 0 }; int i;
for (i = 0; i < n; i++) t[i] = i; return t; }
Au point que je n'osais plus faire renvoyer de pointeur à une fonction. Il faut bien comprendre qu'il y a plein de situations où on peut renvoyer un pointeur vers quelque chose qui "ressemble" à une variable locale (typiquement strchr()) et c'est pas du tout évident de discerner les différentes situations quand on est débutant et même débutant avancé. Et puis tu as la situation de la mémoire allouée. D'ailleurs, c'est en analysant tout cela que j'ai compris que le mot variable est un mot qui est source de beaucoup de confusion. Le bon mot est le mot "objet", c'est un mot qui fait peur (comme le mot "identificateur") mais c'est surtout parce qu'il est expliqué de manière abstraite, non instanciée. D'une façon générale, les exposés, in vivo ou livresques, sont beaucoup trop verbeux et abstraits et dénués d'exemples _bien choisis_ (parce que des exemples qui obscursissent, ça oui, on en trouve).
Non, je ne pense pas que tu aies besoin de connaître quoi que ce soit en archi pour comprendre ça, d'ailleurs, ce principe est indépendant de l'architecture. Je reconnais que j'ai eu du mal comprendre ce phénomène, qui sait si j'aurais mieux capté si j'avais eu des connaissances en archi (m'enfin quand je vois mes étudiants de L3 le faire alors qu'ils sont suivi des cours d'archi, j'ai des doutes). Je pense surtout que ces abstractions sont mal enseignées, en particulier, la tendance majoritaire est à croire qu'on enseigne des abstractions par l'abstraction.
Et oui. Pourquoi faire des gammes sur un piano ? De toute façon, c'est une spécificité de l'informatique et de sa copie facile: quelque soit le sujet que l'on puisse imaginer pour un exercice de TD/TP (ie réalisable en 1-3h), il en existe déjà au moins 50 implantations sur Google...
Ce n'est pas le problème de la copie, c'est le problème du désir de coder. strcmp ne donne pas envie de coder (à moi, oui, à beaucoup d'étudiants, non ou pas présenté tel quel).
Ceci dit, j'ai jamais entendu un élève se plaindre de devoir dériver une fonction cos( x^2 ) / x sous prétexte que quelqu'un a déjà du le faire avant...
Aucun rapport, les étudiants adorent faire ça car ils sont dans la répétition d'une procédure automatique mais avec l'avantage que chaque fois qu'on change de fonction, ils ont l'impression de faire quelque chose de différent ...
Par contre si tu leur demandes de démontrer qu'un fonction paire dérivable a sa dérivée nulle en zéro, ils vont sentir monter l'angoisse en eux.
C'est un peu pareil pour coder strcmp(), memcpy, etc : c'est difficile, chaque réponse est différente de la précédente même si les questions se ressemblent.
Marc Boyer a écrit :
Je ne pense pas que ce soit vrai: on apprécise toujours de pouvoir faire
des liens entre connaissances, et ces liens (sous réserve qu'ils soient
vrais), confortent les apprentissage.
Question d'équilibre car il y a un risque de surcharge. Mon principe
d'enseignement favori : le rasoir d'Occam.
Mais il est tout à fait possible de s'en passer.
Oui, je l'ai fait.
La mémoire est une abstraction et elle peut rester telle quand on
enseigne le C.
Mais il faut présenter cette abstration, l'enseigner.
Oui, et c'est un manque certain dans les cours de C, in vivo ou imprimés, pardon
pour les collègues.
Pas besoin d'aller bien loin. Tiens, retourner un pointeur sur
une variable locale de fonction, et manipuler cette valeur...
Il me semble que ce n'est pas le plus courant que l'on rencontre. D'ailleurs, je
trouve que le mot "variable" est très trompeur. Le cas que j'ai en mémoire (!)
est le suivant :
int *remplirMal(int n)
{
int t[100] = { 0 };
int i;
for (i = 0; i < n; i++)
t[i] = i;
return t;
}
Au point que je n'osais plus faire renvoyer de pointeur à une fonction. Il faut
bien comprendre qu'il y a plein de situations où on peut renvoyer un pointeur
vers quelque chose qui "ressemble" à une variable locale (typiquement strchr())
et c'est pas du tout évident de discerner les différentes situations quand on
est débutant et même débutant avancé. Et puis tu as la situation de la mémoire
allouée. D'ailleurs, c'est en analysant tout cela que j'ai compris que le mot
variable est un mot qui est source de beaucoup de confusion. Le bon mot est le
mot "objet", c'est un mot qui fait peur (comme le mot "identificateur") mais
c'est surtout parce qu'il est expliqué de manière abstraite, non instanciée.
D'une façon générale, les exposés, in vivo ou livresques, sont beaucoup trop
verbeux et abstraits et dénués d'exemples _bien choisis_ (parce que des exemples
qui obscursissent, ça oui, on en trouve).
Non, je ne pense pas que tu aies besoin de connaître quoi que ce soit en archi
pour comprendre ça, d'ailleurs, ce principe est indépendant de l'architecture.
Je reconnais que j'ai eu du mal comprendre ce phénomène, qui sait si j'aurais
mieux capté si j'avais eu des connaissances en archi (m'enfin quand je vois mes
étudiants de L3 le faire alors qu'ils sont suivi des cours d'archi, j'ai des
doutes). Je pense surtout que ces abstractions sont mal enseignées, en
particulier, la tendance majoritaire est à croire qu'on enseigne des
abstractions par l'abstraction.
Et oui. Pourquoi faire des gammes sur un piano ? De toute façon, c'est une
spécificité de l'informatique et de sa copie facile: quelque soit le sujet
que l'on puisse imaginer pour un exercice de TD/TP (ie réalisable en 1-3h),
il en existe déjà au moins 50 implantations sur Google...
Ce n'est pas le problème de la copie, c'est le problème du désir de coder.
strcmp ne donne pas envie de coder (à moi, oui, à beaucoup d'étudiants, non ou
pas présenté tel quel).
Ceci dit, j'ai jamais entendu un élève se plaindre de devoir dériver
une fonction cos( x^2 ) / x sous prétexte que quelqu'un a déjà du le
faire avant...
Aucun rapport, les étudiants adorent faire ça car ils sont dans la répétition
d'une procédure automatique mais avec l'avantage que chaque fois qu'on change de
fonction, ils ont l'impression de faire quelque chose de différent ...
Par contre si tu leur demandes de démontrer qu'un fonction paire dérivable a sa
dérivée nulle en zéro, ils vont sentir monter l'angoisse en eux.
C'est un peu pareil pour coder strcmp(), memcpy, etc : c'est difficile, chaque
réponse est différente de la précédente même si les questions se ressemblent.
Je ne pense pas que ce soit vrai: on apprécise toujours de pouvoir faire des liens entre connaissances, et ces liens (sous réserve qu'ils soient vrais), confortent les apprentissage.
Question d'équilibre car il y a un risque de surcharge. Mon principe d'enseignement favori : le rasoir d'Occam.
Mais il est tout à fait possible de s'en passer.
Oui, je l'ai fait.
La mémoire est une abstraction et elle peut rester telle quand on enseigne le C.
Mais il faut présenter cette abstration, l'enseigner.
Oui, et c'est un manque certain dans les cours de C, in vivo ou imprimés, pardon pour les collègues.
Pas besoin d'aller bien loin. Tiens, retourner un pointeur sur une variable locale de fonction, et manipuler cette valeur...
Il me semble que ce n'est pas le plus courant que l'on rencontre. D'ailleurs, je trouve que le mot "variable" est très trompeur. Le cas que j'ai en mémoire (!) est le suivant :
int *remplirMal(int n) { int t[100] = { 0 }; int i;
for (i = 0; i < n; i++) t[i] = i; return t; }
Au point que je n'osais plus faire renvoyer de pointeur à une fonction. Il faut bien comprendre qu'il y a plein de situations où on peut renvoyer un pointeur vers quelque chose qui "ressemble" à une variable locale (typiquement strchr()) et c'est pas du tout évident de discerner les différentes situations quand on est débutant et même débutant avancé. Et puis tu as la situation de la mémoire allouée. D'ailleurs, c'est en analysant tout cela que j'ai compris que le mot variable est un mot qui est source de beaucoup de confusion. Le bon mot est le mot "objet", c'est un mot qui fait peur (comme le mot "identificateur") mais c'est surtout parce qu'il est expliqué de manière abstraite, non instanciée. D'une façon générale, les exposés, in vivo ou livresques, sont beaucoup trop verbeux et abstraits et dénués d'exemples _bien choisis_ (parce que des exemples qui obscursissent, ça oui, on en trouve).
Non, je ne pense pas que tu aies besoin de connaître quoi que ce soit en archi pour comprendre ça, d'ailleurs, ce principe est indépendant de l'architecture. Je reconnais que j'ai eu du mal comprendre ce phénomène, qui sait si j'aurais mieux capté si j'avais eu des connaissances en archi (m'enfin quand je vois mes étudiants de L3 le faire alors qu'ils sont suivi des cours d'archi, j'ai des doutes). Je pense surtout que ces abstractions sont mal enseignées, en particulier, la tendance majoritaire est à croire qu'on enseigne des abstractions par l'abstraction.
Et oui. Pourquoi faire des gammes sur un piano ? De toute façon, c'est une spécificité de l'informatique et de sa copie facile: quelque soit le sujet que l'on puisse imaginer pour un exercice de TD/TP (ie réalisable en 1-3h), il en existe déjà au moins 50 implantations sur Google...
Ce n'est pas le problème de la copie, c'est le problème du désir de coder. strcmp ne donne pas envie de coder (à moi, oui, à beaucoup d'étudiants, non ou pas présenté tel quel).
Ceci dit, j'ai jamais entendu un élève se plaindre de devoir dériver une fonction cos( x^2 ) / x sous prétexte que quelqu'un a déjà du le faire avant...
Aucun rapport, les étudiants adorent faire ça car ils sont dans la répétition d'une procédure automatique mais avec l'avantage que chaque fois qu'on change de fonction, ils ont l'impression de faire quelque chose de différent ...
Par contre si tu leur demandes de démontrer qu'un fonction paire dérivable a sa dérivée nulle en zéro, ils vont sentir monter l'angoisse en eux.
C'est un peu pareil pour coder strcmp(), memcpy, etc : c'est difficile, chaque réponse est différente de la précédente même si les questions se ressemblent.
espie
In article <4aae3151$0$22542$, candide wrote:
Marc Boyer a écrit :
Je ne pense pas que ce soit vrai: on apprécise toujours de pouvoir faire des liens entre connaissances, et ces liens (sous réserve qu'ils soient vrais), confortent les apprentissage.
Question d'équilibre car il y a un risque de surcharge. Mon principe d'enseignement favori : le rasoir d'Occam.
Ca depend de ce que tu dois enseigner. Moi l'idee, c'est de les confronter a la realite du code existant, a terme. Donc je ne peux pas trop simplifier, ni abandonner des trucs. Ou alors, tu te retrouves a leur presenter un langage "jouet" qui ressemble a du C... apres, ca te fait des programmeurs qui s'integrent mal a d'autres equipes, qui ont un style tres particulier et bizarre... alors qu'il y a quand meme un style a peu pres standard de codage en C (qui vaut ce qu'il vaut, mais au moins, les gens ne sont pas paumes en le lisant).
In article <4aae3151$0$22542$426a34cc@news.free.fr>,
candide <candide@free.invalid> wrote:
Marc Boyer a écrit :
Je ne pense pas que ce soit vrai: on apprécise toujours de pouvoir faire
des liens entre connaissances, et ces liens (sous réserve qu'ils soient
vrais), confortent les apprentissage.
Question d'équilibre car il y a un risque de surcharge. Mon principe
d'enseignement favori : le rasoir d'Occam.
Ca depend de ce que tu dois enseigner. Moi l'idee, c'est de les confronter
a la realite du code existant, a terme. Donc je ne peux pas trop simplifier,
ni abandonner des trucs. Ou alors, tu te retrouves a leur presenter un
langage "jouet" qui ressemble a du C... apres, ca te fait des programmeurs
qui s'integrent mal a d'autres equipes, qui ont un style tres particulier
et bizarre... alors qu'il y a quand meme un style a peu pres standard de
codage en C (qui vaut ce qu'il vaut, mais au moins, les gens ne sont pas
paumes en le lisant).
Je ne pense pas que ce soit vrai: on apprécise toujours de pouvoir faire des liens entre connaissances, et ces liens (sous réserve qu'ils soient vrais), confortent les apprentissage.
Question d'équilibre car il y a un risque de surcharge. Mon principe d'enseignement favori : le rasoir d'Occam.
Ca depend de ce que tu dois enseigner. Moi l'idee, c'est de les confronter a la realite du code existant, a terme. Donc je ne peux pas trop simplifier, ni abandonner des trucs. Ou alors, tu te retrouves a leur presenter un langage "jouet" qui ressemble a du C... apres, ca te fait des programmeurs qui s'integrent mal a d'autres equipes, qui ont un style tres particulier et bizarre... alors qu'il y a quand meme un style a peu pres standard de codage en C (qui vaut ce qu'il vaut, mais au moins, les gens ne sont pas paumes en le lisant).
Marc Boyer
Le 14-09-2009, Gabriel Dos Reis a écrit :
Marc Boyer writes: | Et oui. Pourquoi faire des gammes sur un piano ? De toute façon, c'est une | spécificité de l'informatique et de sa copie facile: quelque soit le sujet | que l'on puisse imaginer pour un exercice de TD/TP (ie réalisable en 1-3h), | il en existe déjà au moins 50 implantations sur Google...
Fais leur écrire des *programmes*. Oui, ils trouveront des programmes similaires sur Google ; mais au moins ils sauront ce que c'est qu'un programme.
C'est vrai que les TD se focalisaient surtout sur les sous-programmes, pour pouvoir insister sur les contrats (precondition surtout), la documentation et les tests unitaires (avec en ligne de mire la question de la maintenance).
Après, de tout façon en TP, la seule façon de tester que je connaisse en C, c'est de faire un programme.
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
Le 14-09-2009, Gabriel Dos Reis <gdr@cs.tamu.edu> a écrit :
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
| Et oui. Pourquoi faire des gammes sur un piano ? De toute façon, c'est une
| spécificité de l'informatique et de sa copie facile: quelque soit le sujet
| que l'on puisse imaginer pour un exercice de TD/TP (ie réalisable en 1-3h),
| il en existe déjà au moins 50 implantations sur Google...
Fais leur écrire des *programmes*. Oui, ils trouveront des programmes
similaires sur Google ; mais au moins ils sauront ce que c'est qu'un
programme.
C'est vrai que les TD se focalisaient surtout sur les sous-programmes,
pour pouvoir insister sur les contrats (precondition surtout),
la documentation et les tests unitaires (avec en ligne de mire la
question de la maintenance).
Après, de tout façon en TP, la seule façon de tester que je connaisse
en C, c'est de faire un programme.
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 writes: | Et oui. Pourquoi faire des gammes sur un piano ? De toute façon, c'est une | spécificité de l'informatique et de sa copie facile: quelque soit le sujet | que l'on puisse imaginer pour un exercice de TD/TP (ie réalisable en 1-3h), | il en existe déjà au moins 50 implantations sur Google...
Fais leur écrire des *programmes*. Oui, ils trouveront des programmes similaires sur Google ; mais au moins ils sauront ce que c'est qu'un programme.
C'est vrai que les TD se focalisaient surtout sur les sous-programmes, pour pouvoir insister sur les contrats (precondition surtout), la documentation et les tests unitaires (avec en ligne de mire la question de la maintenance).
Après, de tout façon en TP, la seule façon de tester que je connaisse en C, c'est de faire un programme.
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
espie
In article <h8lbvp$6mi$, Marc Boyer wrote:
C'est vrai que les TD se focalisaient surtout sur les sous-programmes, pour pouvoir insister sur les contrats (precondition surtout), la documentation et les tests unitaires (avec en ligne de mire la question de la maintenance).
Après, de tout façon en TP, la seule façon de tester que je connaisse en C, c'est de faire un programme.
Faut avouer aussi que j'ai en ligne de mire un cours de "securite du developpement", et que le constat industriel actuel est atrocement negatif... d'ou leur apprendre a programmer au plus simple, leur rappeler que quoi qu'ils fassent, ils vont faire des bugs, et que donc rendre le code le plus simple possible a tester est indispensable...
In article <h8lbvp$6mi$1@news.cict.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
C'est vrai que les TD se focalisaient surtout sur les sous-programmes,
pour pouvoir insister sur les contrats (precondition surtout),
la documentation et les tests unitaires (avec en ligne de mire la
question de la maintenance).
Après, de tout façon en TP, la seule façon de tester que je connaisse
en C, c'est de faire un programme.
Faut avouer aussi que j'ai en ligne de mire un cours de "securite du
developpement", et que le constat industriel actuel est atrocement
negatif... d'ou leur apprendre a programmer au plus simple, leur rappeler
que quoi qu'ils fassent, ils vont faire des bugs, et que donc rendre le
code le plus simple possible a tester est indispensable...
C'est vrai que les TD se focalisaient surtout sur les sous-programmes, pour pouvoir insister sur les contrats (precondition surtout), la documentation et les tests unitaires (avec en ligne de mire la question de la maintenance).
Après, de tout façon en TP, la seule façon de tester que je connaisse en C, c'est de faire un programme.
Faut avouer aussi que j'ai en ligne de mire un cours de "securite du developpement", et que le constat industriel actuel est atrocement negatif... d'ou leur apprendre a programmer au plus simple, leur rappeler que quoi qu'ils fassent, ils vont faire des bugs, et que donc rendre le code le plus simple possible a tester est indispensable...
Gabriel Dos Reis
(Marc Espie) writes:
| In article <4aae3151$0$22542$, | candide wrote: | >Marc Boyer a écrit : | > | >> Je ne pense pas que ce soit vrai: on apprécise toujours de pouvoir faire | >> des liens entre connaissances, et ces liens (sous réserve qu'ils soient | >> vrais), confortent les apprentissage. | > | > | >Question d'équilibre car il y a un risque de surcharge. Mon principe | >d'enseignement favori : le rasoir d'Occam. | | Ca depend de ce que tu dois enseigner. Moi l'idee, c'est de les confronter | a la realite du code existant, a terme. Donc je ne peux pas trop simplifier, | ni abandonner des trucs. Ou alors, tu te retrouves a leur presenter un | langage "jouet" qui ressemble a du C... apres, ca te fait des programmeurs | qui s'integrent mal a d'autres equipes, qui ont un style tres particulier | et bizarre... alors qu'il y a quand meme un style a peu pres standard de | codage en C (qui vaut ce qu'il vaut, mais au moins, les gens ne sont pas | paumes en le lisant).
En effet, la question est : quel est le but du cours ? Former des gens qui, à la fin, peuvent écrire des programmes de tailles modérées, peuvent s'intégrer dans une équipe ? Ou une tête remplie de connaissance livresque ?
-- Gaby
espie@lain.home (Marc Espie) writes:
| In article <4aae3151$0$22542$426a34cc@news.free.fr>,
| candide <candide@free.invalid> wrote:
| >Marc Boyer a écrit :
| >
| >> Je ne pense pas que ce soit vrai: on apprécise toujours de pouvoir faire
| >> des liens entre connaissances, et ces liens (sous réserve qu'ils soient
| >> vrais), confortent les apprentissage.
| >
| >
| >Question d'équilibre car il y a un risque de surcharge. Mon principe
| >d'enseignement favori : le rasoir d'Occam.
|
| Ca depend de ce que tu dois enseigner. Moi l'idee, c'est de les confronter
| a la realite du code existant, a terme. Donc je ne peux pas trop simplifier,
| ni abandonner des trucs. Ou alors, tu te retrouves a leur presenter un
| langage "jouet" qui ressemble a du C... apres, ca te fait des programmeurs
| qui s'integrent mal a d'autres equipes, qui ont un style tres particulier
| et bizarre... alors qu'il y a quand meme un style a peu pres standard de
| codage en C (qui vaut ce qu'il vaut, mais au moins, les gens ne sont pas
| paumes en le lisant).
En effet, la question est : quel est le but du cours ? Former des gens
qui, à la fin, peuvent écrire des programmes de tailles modérées, peuvent
s'intégrer dans une équipe ? Ou une tête remplie de connaissance livresque ?
| In article <4aae3151$0$22542$, | candide wrote: | >Marc Boyer a écrit : | > | >> Je ne pense pas que ce soit vrai: on apprécise toujours de pouvoir faire | >> des liens entre connaissances, et ces liens (sous réserve qu'ils soient | >> vrais), confortent les apprentissage. | > | > | >Question d'équilibre car il y a un risque de surcharge. Mon principe | >d'enseignement favori : le rasoir d'Occam. | | Ca depend de ce que tu dois enseigner. Moi l'idee, c'est de les confronter | a la realite du code existant, a terme. Donc je ne peux pas trop simplifier, | ni abandonner des trucs. Ou alors, tu te retrouves a leur presenter un | langage "jouet" qui ressemble a du C... apres, ca te fait des programmeurs | qui s'integrent mal a d'autres equipes, qui ont un style tres particulier | et bizarre... alors qu'il y a quand meme un style a peu pres standard de | codage en C (qui vaut ce qu'il vaut, mais au moins, les gens ne sont pas | paumes en le lisant).
En effet, la question est : quel est le but du cours ? Former des gens qui, à la fin, peuvent écrire des programmes de tailles modérées, peuvent s'intégrer dans une équipe ? Ou une tête remplie de connaissance livresque ?
-- Gaby
Stephane Legras-Decussy
"Marc Espie" a écrit dans le message de news: h8l8md$i65$
... et ca met parfaitement en evidence *le* probleme central des pointeurs/references, qui est le probleme d'identite des objets non scalaires...
plus simplement j'ai constaté que le débutant est completement perdu à cause de '*' qui dans un cas déclare le pointeur int *p et dans l'autre cas est un opérateur a = *p
c'est vrai que c'est pas très malin d'avoir fait ça...
"Marc Espie" <espie@lain.home> a écrit dans le message de news:
h8l8md$i65$4@saria.nerim.net...
... et ca met parfaitement en evidence *le* probleme central des
pointeurs/references, qui est le probleme d'identite des objets non
scalaires...
plus simplement j'ai constaté que le débutant
est completement perdu à cause de '*'
qui dans un cas déclare le pointeur int *p
et dans l'autre cas est un opérateur a = *p
c'est vrai que c'est pas très malin d'avoir fait
ça...
"Marc Espie" a écrit dans le message de news: h8l8md$i65$
... et ca met parfaitement en evidence *le* probleme central des pointeurs/references, qui est le probleme d'identite des objets non scalaires...
plus simplement j'ai constaté que le débutant est completement perdu à cause de '*' qui dans un cas déclare le pointeur int *p et dans l'autre cas est un opérateur a = *p
c'est vrai que c'est pas très malin d'avoir fait ça...
Marc Boyer
Le 14-09-2009, Gabriel Dos Reis a écrit :
Marc Boyer writes:
[...]
| Nous, on faisait le contraire. On leur donnait la spec de strcpy, et | on demandait de le coder, en précisant bien que c'était pour l'exercice, | et que dans la "vraie vie", on utilisait strncpy, où sa propre | bibliothèque de chaine de char (on en faisait 2 différentes).
Savent-ils pourquoi ils font ça ?
On leur expliquait.
Sauront-ils écrire des programmes après ça ?
Après quoi ? Après un TD sur strcpy, surement pas. Après les 10 TD + 10 TP + le projet, c'était raisonnable.
Il y a une différence fondamentale entre écrire une bibliothèque et écrire un programme. Savoir implémenter une bibliothèque a des exigences souvent assez différentes de celles requises pour écrire un programme.
Oui et non. Une bibliothèque a souvent des exigence de portabilité qu'un simple programme n'a pas. Mais même quand on écrit un programme, il faut se poser la question des plateformes d'exécution visées. Ensuite, le découpage d'un programme en modules implique un travail de définitions d'interface.
Quelles différences spécifique fais-tu toi ?
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
Le 14-09-2009, Gabriel Dos Reis <gdr@cs.tamu.edu> a écrit :
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
[...]
| Nous, on faisait le contraire. On leur donnait la spec de strcpy, et
| on demandait de le coder, en précisant bien que c'était pour l'exercice,
| et que dans la "vraie vie", on utilisait strncpy, où sa propre
| bibliothèque de chaine de char (on en faisait 2 différentes).
Savent-ils pourquoi ils font ça ?
On leur expliquait.
Sauront-ils écrire des programmes après ça ?
Après quoi ? Après un TD sur strcpy, surement pas. Après
les 10 TD + 10 TP + le projet, c'était raisonnable.
Il y a une différence fondamentale entre écrire une
bibliothèque et écrire un programme. Savoir implémenter une bibliothèque
a des exigences souvent assez différentes de celles requises pour écrire
un programme.
Oui et non.
Une bibliothèque a souvent des exigence de portabilité qu'un
simple programme n'a pas. Mais même quand on écrit un programme,
il faut se poser la question des plateformes d'exécution visées.
Ensuite, le découpage d'un programme en modules implique un travail
de définitions d'interface.
Quelles différences spécifique fais-tu toi ?
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
| Nous, on faisait le contraire. On leur donnait la spec de strcpy, et | on demandait de le coder, en précisant bien que c'était pour l'exercice, | et que dans la "vraie vie", on utilisait strncpy, où sa propre | bibliothèque de chaine de char (on en faisait 2 différentes).
Savent-ils pourquoi ils font ça ?
On leur expliquait.
Sauront-ils écrire des programmes après ça ?
Après quoi ? Après un TD sur strcpy, surement pas. Après les 10 TD + 10 TP + le projet, c'était raisonnable.
Il y a une différence fondamentale entre écrire une bibliothèque et écrire un programme. Savoir implémenter une bibliothèque a des exigences souvent assez différentes de celles requises pour écrire un programme.
Oui et non. Une bibliothèque a souvent des exigence de portabilité qu'un simple programme n'a pas. Mais même quand on écrit un programme, il faut se poser la question des plateformes d'exécution visées. Ensuite, le découpage d'un programme en modules implique un travail de définitions d'interface.
Quelles différences spécifique fais-tu toi ?
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
Marc Boyer a écrit :
Tu va au devant de 3 problèmes avec les biblo graphiques: - d'abord, t'es obligé de présenter des "commandes magiques" pour que ça marche (genre #include <titi.h> + compilation avec -I /usr/lib...),
Non, la SDL ou ncurses marche aussi facilement que si tu utilises des fonctions de math.h, suffit de lier genre -lncurses .
te les faire installer sur les machines (et les universités sont pas toutes riches en ingé système),
Ya rien à faire, ya des paquet tout prets.
et devoir déboguer des usages bizares de la lib que tu n'avais pas imaginé
Le but n'est pas de faire de la programmation graphique, c'est d'utiliser une lib non standard et de se familiariser à certaines généralités (instanciées dans ta lib graphique).
- un bon nombre d'étudiants passent leur temps à vouloir changer la couleur de fond, la fonte, et passent à côté de l'objectif de l'enseignement,
Tu peux poser des limites. Je répète le but n'est pas de faire de la programmation graphique.
- les bibliothèques d'IHM fonctionnent sur une prog évenementielle (ce qu'on appelait "callback"), qui demande encore du temps de présentation.
OK mais ça c'est autre chose, toi tu parles de programmer un GUI (genre GTK) mais là on s'éloigne de l'apprentissage du C. Tu peux faire un peu de programmation graphique pour apprendre à utiliser une bibliothèque non standard sans faire de programmation événementielle (ou alors très limitée) parce que sinon tu vas rentrer dans des détails qui n'ont plus rien à voir avec l'apprentissage du C.
Ca, en 2009, baser un cours d'algorithmique sur le C me semble un bien mauvais choix.
Il ne s'agit pas d'un cours d'algorithmique à proprement parler, il s'agit de faire des expérimentations algorithmiques. Tu disposes d'un langage de programmation et tu cherches à résoudre des problèmes de nature algorithmique en utilisant ce langage (vu comme un outil).
Enseigner le C ne se justifie que si on considère le C comme un langage dans le domaine professionnel de la formation.
Et bien, nombreuses sont les facs où on enseigne le C aux étudiants de maths et de physique jusqu'en L2 voire L3 (pour des méthodes numériques par exemple).
Marc Boyer a écrit :
Tu va au devant de 3 problèmes avec les biblo graphiques:
- d'abord, t'es obligé de présenter des "commandes magiques" pour que
ça marche (genre #include <titi.h> + compilation avec -I /usr/lib...),
Non, la SDL ou ncurses marche aussi facilement que si tu utilises des fonctions
de math.h, suffit de lier genre -lncurses .
te les faire installer sur les machines (et les universités sont pas
toutes riches en ingé système),
Ya rien à faire, ya des paquet tout prets.
et devoir déboguer des usages bizares
de la lib que tu n'avais pas imaginé
Le but n'est pas de faire de la programmation graphique, c'est d'utiliser une
lib non standard et de se familiariser à certaines généralités (instanciées dans
ta lib graphique).
- un bon nombre d'étudiants passent leur temps à vouloir changer la
couleur de fond, la fonte, et passent à côté de l'objectif de
l'enseignement,
Tu peux poser des limites. Je répète le but n'est pas de faire de la
programmation graphique.
- les bibliothèques d'IHM fonctionnent sur une prog évenementielle
(ce qu'on appelait "callback"), qui demande encore du temps de
présentation.
OK mais ça c'est autre chose, toi tu parles de programmer un GUI (genre GTK)
mais là on s'éloigne de l'apprentissage du C. Tu peux faire un peu de
programmation graphique pour apprendre à utiliser une bibliothèque non standard
sans faire de programmation événementielle (ou alors très limitée) parce que
sinon tu vas rentrer dans des détails qui n'ont plus rien à voir avec
l'apprentissage du C.
Ca, en 2009, baser un cours d'algorithmique sur le C me semble un bien mauvais
choix.
Il ne s'agit pas d'un cours d'algorithmique à proprement parler, il s'agit de
faire des expérimentations algorithmiques. Tu disposes d'un langage de
programmation et tu cherches à résoudre des problèmes de nature algorithmique en
utilisant ce langage (vu comme un outil).
Enseigner le C ne se justifie que si on considère le C comme un langage
dans le domaine professionnel de la formation.
Et bien, nombreuses sont les facs où on enseigne le C aux étudiants de maths et
de physique jusqu'en L2 voire L3 (pour des méthodes numériques par exemple).
Tu va au devant de 3 problèmes avec les biblo graphiques: - d'abord, t'es obligé de présenter des "commandes magiques" pour que ça marche (genre #include <titi.h> + compilation avec -I /usr/lib...),
Non, la SDL ou ncurses marche aussi facilement que si tu utilises des fonctions de math.h, suffit de lier genre -lncurses .
te les faire installer sur les machines (et les universités sont pas toutes riches en ingé système),
Ya rien à faire, ya des paquet tout prets.
et devoir déboguer des usages bizares de la lib que tu n'avais pas imaginé
Le but n'est pas de faire de la programmation graphique, c'est d'utiliser une lib non standard et de se familiariser à certaines généralités (instanciées dans ta lib graphique).
- un bon nombre d'étudiants passent leur temps à vouloir changer la couleur de fond, la fonte, et passent à côté de l'objectif de l'enseignement,
Tu peux poser des limites. Je répète le but n'est pas de faire de la programmation graphique.
- les bibliothèques d'IHM fonctionnent sur une prog évenementielle (ce qu'on appelait "callback"), qui demande encore du temps de présentation.
OK mais ça c'est autre chose, toi tu parles de programmer un GUI (genre GTK) mais là on s'éloigne de l'apprentissage du C. Tu peux faire un peu de programmation graphique pour apprendre à utiliser une bibliothèque non standard sans faire de programmation événementielle (ou alors très limitée) parce que sinon tu vas rentrer dans des détails qui n'ont plus rien à voir avec l'apprentissage du C.
Ca, en 2009, baser un cours d'algorithmique sur le C me semble un bien mauvais choix.
Il ne s'agit pas d'un cours d'algorithmique à proprement parler, il s'agit de faire des expérimentations algorithmiques. Tu disposes d'un langage de programmation et tu cherches à résoudre des problèmes de nature algorithmique en utilisant ce langage (vu comme un outil).
Enseigner le C ne se justifie que si on considère le C comme un langage dans le domaine professionnel de la formation.
Et bien, nombreuses sont les facs où on enseigne le C aux étudiants de maths et de physique jusqu'en L2 voire L3 (pour des méthodes numériques par exemple).
candide
Pierre Maurette a écrit :
candide, le 14/09/2009 a écrit :
[...]
Un dégogueur utilisé comme un VCR (arrêt sur image, avance rapide, etc)
Le pas à pas en arrière est rare,
Tiens je m'étais posé la question si c'était possible et la doc de gdb ne m'avait pas vraiment aidé (à quand dans les manuels une rubrique non pas de ce qu'on peut faire mais de ce qu'on ne peut pas faire).
(...) Modification et compilation nécessaire.
Ah,non merci, trop compliqué pour moi. C'est là que je vois que je ne suis pas un vrai informaticien ...
Pierre Maurette a écrit :
candide, le 14/09/2009 a écrit :
[...]
Un dégogueur utilisé comme un VCR (arrêt sur image, avance rapide, etc)
Le pas à pas en arrière est rare,
Tiens je m'étais posé la question si c'était possible et la doc de gdb ne
m'avait pas vraiment aidé (à quand dans les manuels une rubrique non pas de ce
qu'on peut faire mais de ce qu'on ne peut pas faire).
(...) Modification
et compilation nécessaire.
Ah,non merci, trop compliqué pour moi. C'est là que je vois que je ne suis pas
un vrai informaticien ...
Un dégogueur utilisé comme un VCR (arrêt sur image, avance rapide, etc)
Le pas à pas en arrière est rare,
Tiens je m'étais posé la question si c'était possible et la doc de gdb ne m'avait pas vraiment aidé (à quand dans les manuels une rubrique non pas de ce qu'on peut faire mais de ce qu'on ne peut pas faire).
(...) Modification et compilation nécessaire.
Ah,non merci, trop compliqué pour moi. C'est là que je vois que je ne suis pas un vrai informaticien ...
Gabriel Dos Reis
(Marc Espie) writes:
| In article <h8lbvp$6mi$, | Marc Boyer wrote: | > C'est vrai que les TD se focalisaient surtout sur les sous-programmes, | >pour pouvoir insister sur les contrats (precondition surtout), | >la documentation et les tests unitaires (avec en ligne de mire la | >question de la maintenance). | > | > Après, de tout façon en TP, la seule façon de tester que je connaisse | >en C, c'est de faire un programme. | > | | Faut avouer aussi que j'ai en ligne de mire un cours de "securite du | developpement", et que le constat industriel actuel est atrocement | negatif... d'ou leur apprendre a programmer au plus simple, leur rappeler | que quoi qu'ils fassent, ils vont faire des bugs, et que donc rendre le | code le plus simple possible a tester est indispensable...
Je les fais travailler sur des projets en équipes (3 personnes par équipes, c'est déjà trop) sur le même sujet. Les projets progressent par étapes. En cours de projet (en général chaque semaine), je change légèrement les contraintes. Par exemple, je leur dis qu'ils doivent donner leur API à une équipe, et en même temps, hériter d'une autre équipe. Ils doivent implémenter ce qu'ils ont herité. Après, je leur demande de donner leurs implémentations à une équipe et heriter du travail produit d'une autre. Etc.
Cela les force à éviter d'écrire des programmes pour eux mêmes -- en général, ils apprécient très vite la notion de documentation et la simplicité :-)
-- Gaby
espie@lain.home (Marc Espie) writes:
| In article <h8lbvp$6mi$1@news.cict.fr>,
| Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
| > C'est vrai que les TD se focalisaient surtout sur les sous-programmes,
| >pour pouvoir insister sur les contrats (precondition surtout),
| >la documentation et les tests unitaires (avec en ligne de mire la
| >question de la maintenance).
| >
| > Après, de tout façon en TP, la seule façon de tester que je connaisse
| >en C, c'est de faire un programme.
| >
|
| Faut avouer aussi que j'ai en ligne de mire un cours de "securite du
| developpement", et que le constat industriel actuel est atrocement
| negatif... d'ou leur apprendre a programmer au plus simple, leur rappeler
| que quoi qu'ils fassent, ils vont faire des bugs, et que donc rendre le
| code le plus simple possible a tester est indispensable...
Je les fais travailler sur des projets en équipes (3 personnes par
équipes, c'est déjà trop) sur le même sujet. Les projets progressent
par étapes. En cours de projet (en général chaque semaine), je change
légèrement les contraintes. Par exemple, je leur dis qu'ils doivent
donner leur API à une équipe, et en même temps, hériter d'une
autre équipe. Ils doivent implémenter ce qu'ils ont herité.
Après, je leur demande de donner leurs implémentations à une
équipe et heriter du travail produit d'une autre. Etc.
Cela les force à éviter d'écrire des programmes pour eux mêmes -- en
général, ils apprécient très vite la notion de documentation et la
simplicité :-)
| In article <h8lbvp$6mi$, | Marc Boyer wrote: | > C'est vrai que les TD se focalisaient surtout sur les sous-programmes, | >pour pouvoir insister sur les contrats (precondition surtout), | >la documentation et les tests unitaires (avec en ligne de mire la | >question de la maintenance). | > | > Après, de tout façon en TP, la seule façon de tester que je connaisse | >en C, c'est de faire un programme. | > | | Faut avouer aussi que j'ai en ligne de mire un cours de "securite du | developpement", et que le constat industriel actuel est atrocement | negatif... d'ou leur apprendre a programmer au plus simple, leur rappeler | que quoi qu'ils fassent, ils vont faire des bugs, et que donc rendre le | code le plus simple possible a tester est indispensable...
Je les fais travailler sur des projets en équipes (3 personnes par équipes, c'est déjà trop) sur le même sujet. Les projets progressent par étapes. En cours de projet (en général chaque semaine), je change légèrement les contraintes. Par exemple, je leur dis qu'ils doivent donner leur API à une équipe, et en même temps, hériter d'une autre équipe. Ils doivent implémenter ce qu'ils ont herité. Après, je leur demande de donner leurs implémentations à une équipe et heriter du travail produit d'une autre. Etc.
Cela les force à éviter d'écrire des programmes pour eux mêmes -- en général, ils apprécient très vite la notion de documentation et la simplicité :-)
