é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,
Marc Boyer writes: | Le 11-09-2009, Gabriel Dos Reis a écrit : | > Marc Boyer writes: | > | > [...] | > | >| > Les pointeurs, c'est simple. | >| | >| Voui, mais ça prend plus d'une heure. | > | > Ça dépend. | > | > C'est sûr que si le professeur donne l'impression que c'est compliqué, | > les 2/3 des élèves imprimeront que c'est compliqué. | | Il y a là une contradiction difficile à gérer pour l'enseignant. | D'une part, il sait qu'il faut que les étudiannts soient attentifs | à ce point, et qu'il les prévienne (à moins d'avoir des étudiants | dont l'attention est constante sur tout son cour, ce qui ne m'a | jamais été donné).
Dans mon expérience, commencer un cours par « aujourd'hui on va aborder un sujet difficile » ne capte l'attention de la majorité des élèves que pendans 30 secondes.
Parce que tu manques de charisme. Chez moi, ça dure presque une minute ;-)
| D'autre part, plus on dit que c'est difficile, plus les élèvent | impriment que c'est difficile. | | Quel équilibre ? Je suis preneur de toute solution.
J'ai trouver que moviter ce qu'on va faire (le sujet du cours), expliquer comment ces problèmes surviennent avec des exemples concrets (mais assez simples pour tenir en 50 min ou 1h15min) a souvent beaucoup de chances de retenir leur attention pendant un temps relativement assez long.
50mn de présentation du pourquoi des pointeurs ? Je n'ai jamais eut le loisir d'expérimenter ce genre de chose. Je pense que toute ma partie du cours pointeurs (incluant l'alloc dynamique, les tableaux, et les pointeurs de fonction) devait tenir sur 2h15-2h45..
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:
| Le 11-09-2009, Gabriel Dos Reis <gdr@cs.tamu.edu> a écrit :
| > Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
| >
| > [...]
| >
| >| > Les pointeurs, c'est simple.
| >|
| >| Voui, mais ça prend plus d'une heure.
| >
| > Ça dépend.
| >
| > C'est sûr que si le professeur donne l'impression que c'est compliqué,
| > les 2/3 des élèves imprimeront que c'est compliqué.
|
| Il y a là une contradiction difficile à gérer pour l'enseignant.
| D'une part, il sait qu'il faut que les étudiannts soient attentifs
| à ce point, et qu'il les prévienne (à moins d'avoir des étudiants
| dont l'attention est constante sur tout son cour, ce qui ne m'a
| jamais été donné).
Dans mon expérience, commencer un cours par « aujourd'hui on va aborder
un sujet difficile » ne capte l'attention de la majorité des élèves que
pendans 30 secondes.
Parce que tu manques de charisme. Chez moi, ça dure presque une minute ;-)
| D'autre part, plus on dit que c'est difficile, plus les élèvent
| impriment que c'est difficile.
|
| Quel équilibre ? Je suis preneur de toute solution.
J'ai trouver que moviter ce qu'on va faire (le sujet du cours),
expliquer comment ces problèmes surviennent avec des exemples concrets
(mais assez simples pour tenir en 50 min ou 1h15min) a souvent beaucoup
de chances de retenir leur attention pendant un temps relativement assez
long.
50mn de présentation du pourquoi des pointeurs ? Je n'ai jamais
eut le loisir d'expérimenter ce genre de chose. Je pense que toute ma
partie du cours pointeurs (incluant l'alloc dynamique, les tableaux,
et les pointeurs de fonction) devait tenir sur 2h15-2h45..
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: | Le 11-09-2009, Gabriel Dos Reis a écrit : | > Marc Boyer writes: | > | > [...] | > | >| > Les pointeurs, c'est simple. | >| | >| Voui, mais ça prend plus d'une heure. | > | > Ça dépend. | > | > C'est sûr que si le professeur donne l'impression que c'est compliqué, | > les 2/3 des élèves imprimeront que c'est compliqué. | | Il y a là une contradiction difficile à gérer pour l'enseignant. | D'une part, il sait qu'il faut que les étudiannts soient attentifs | à ce point, et qu'il les prévienne (à moins d'avoir des étudiants | dont l'attention est constante sur tout son cour, ce qui ne m'a | jamais été donné).
Dans mon expérience, commencer un cours par « aujourd'hui on va aborder un sujet difficile » ne capte l'attention de la majorité des élèves que pendans 30 secondes.
Parce que tu manques de charisme. Chez moi, ça dure presque une minute ;-)
| D'autre part, plus on dit que c'est difficile, plus les élèvent | impriment que c'est difficile. | | Quel équilibre ? Je suis preneur de toute solution.
J'ai trouver que moviter ce qu'on va faire (le sujet du cours), expliquer comment ces problèmes surviennent avec des exemples concrets (mais assez simples pour tenir en 50 min ou 1h15min) a souvent beaucoup de chances de retenir leur attention pendant un temps relativement assez long.
50mn de présentation du pourquoi des pointeurs ? Je n'ai jamais eut le loisir d'expérimenter ce genre de chose. Je pense que toute ma partie du cours pointeurs (incluant l'alloc dynamique, les tableaux, et les pointeurs de fonction) devait tenir sur 2h15-2h45..
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
Stephane Legras-Decussy
"Gabriel Dos Reis" a écrit dans le message de news:
ouarf.... la note du projet multipliée par 0.9998^m (m retard en minutes) ....
ça rigole pas !
et en même temps on a super envie de se marrer... :-D
Marc Boyer
Le 14-09-2009, Gabriel Dos Reis a écrit :
Marc Boyer writes:
[...]
| Je présentais la ligne de commande "-Wall -pedantic" dans les 10 premiers | transparents. Et de même que je refusais de lire un code mal indenté, | je refusais de chercher un bug dans un code qui laissait passer des | Warning avec -Wall -pedantic.
Pour le premier devoir de maison, je fais savoir que tout devoir rendu qui ne compile pas avec "-Wall -O2 -pedantic -Werror" est disqualifié.
Je suis un rien laxiste, je n'obligeais pas -Werror.
Oh, j'exige aussi un Makefile pour le second devoir de maison.
Pareil.
(Cette année, le premier TD concerne l'utilisation de SVN -- cela aurait pu être n'importe quel VCS moderne. Après le premier devoir de maison, ils apprennent à écrire un Makefile.)
On se sentait un peu cours en TD pour le faire, mais c'est avec la première scéance de projet.
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:
[...]
| Je présentais la ligne de commande "-Wall -pedantic" dans les 10 premiers
| transparents. Et de même que je refusais de lire un code mal indenté,
| je refusais de chercher un bug dans un code qui laissait passer des
| Warning avec -Wall -pedantic.
Pour le premier devoir de maison, je fais savoir que tout devoir rendu
qui ne compile pas avec "-Wall -O2 -pedantic -Werror" est disqualifié.
Je suis un rien laxiste, je n'obligeais pas -Werror.
Oh, j'exige aussi un Makefile pour le second devoir de maison.
Pareil.
(Cette année, le premier TD concerne l'utilisation de SVN -- cela aurait pu
être n'importe quel VCS moderne. Après le premier devoir de maison, ils
apprennent à écrire un Makefile.)
On se sentait un peu cours en TD pour le faire, mais c'est avec
la première scéance de projet.
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
| Je présentais la ligne de commande "-Wall -pedantic" dans les 10 premiers | transparents. Et de même que je refusais de lire un code mal indenté, | je refusais de chercher un bug dans un code qui laissait passer des | Warning avec -Wall -pedantic.
Pour le premier devoir de maison, je fais savoir que tout devoir rendu qui ne compile pas avec "-Wall -O2 -pedantic -Werror" est disqualifié.
Je suis un rien laxiste, je n'obligeais pas -Werror.
Oh, j'exige aussi un Makefile pour le second devoir de maison.
Pareil.
(Cette année, le premier TD concerne l'utilisation de SVN -- cela aurait pu être n'importe quel VCS moderne. Après le premier devoir de maison, ils apprennent à écrire un Makefile.)
On se sentait un peu cours en TD pour le faire, mais c'est avec la première scéance de projet.
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 <4aae3487$0$7785$, Stephane Legras-Decussy wrote:
"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...
Bof, ca c'est pas un vrai souci, de mon point de vue. Ca depend comment tu expliques. Pour moi, int *p, ca te dit que l'expression *p est de type int. Et donc c'est le meme operateur. Ca demande juste un certain niveau d'abstraction. Personnellement, je passe beaucoup de temps sur les idiomatismes: expliquer aux etudiants que, comme lorsqu'on pratique une langue, on ne passe pas son temps a decortiquer la syntaxe et la grammaire. Non, on voit les trucs en detail une fois, et apres on "monte de niveau", et on oublie tout. Ca se fait generalement en leur expliquant que, dans une boucle telle que:
for (i = 0; i < n; i++) printf("%d ", t[i]);
*personne* ne lit vraiment la boucle, mais tout le monde sait bien que c'est un idiome standard pour afficher tout un tableau.
In article <4aae3487$0$7785$426a74cc@news.free.fr>,
Stephane Legras-Decussy <killyourself@yesnocancel.com> wrote:
"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...
Bof, ca c'est pas un vrai souci, de mon point de vue. Ca depend comment
tu expliques. Pour moi, int *p, ca te dit que l'expression *p est de
type int. Et donc c'est le meme operateur. Ca demande juste un certain
niveau d'abstraction. Personnellement, je passe beaucoup de temps sur les
idiomatismes: expliquer aux etudiants que, comme lorsqu'on pratique une
langue, on ne passe pas son temps a decortiquer la syntaxe et la grammaire.
Non, on voit les trucs en detail une fois, et apres on "monte de niveau", et
on oublie tout. Ca se fait generalement en leur expliquant que, dans une
boucle telle que:
for (i = 0; i < n; i++)
printf("%d ", t[i]);
*personne* ne lit vraiment la boucle, mais tout le monde sait bien que c'est
un idiome standard pour afficher tout un tableau.
In article <4aae3487$0$7785$, Stephane Legras-Decussy wrote:
"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...
Bof, ca c'est pas un vrai souci, de mon point de vue. Ca depend comment tu expliques. Pour moi, int *p, ca te dit que l'expression *p est de type int. Et donc c'est le meme operateur. Ca demande juste un certain niveau d'abstraction. Personnellement, je passe beaucoup de temps sur les idiomatismes: expliquer aux etudiants que, comme lorsqu'on pratique une langue, on ne passe pas son temps a decortiquer la syntaxe et la grammaire. Non, on voit les trucs en detail une fois, et apres on "monte de niveau", et on oublie tout. Ca se fait generalement en leur expliquant que, dans une boucle telle que:
for (i = 0; i < n; i++) printf("%d ", t[i]);
*personne* ne lit vraiment la boucle, mais tout le monde sait bien que c'est un idiome standard pour afficher tout un tableau.
espie
In article <4aae35a7$0$5650$, candide wrote:
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).
Non, gdb ne sait pas vraiment faire... ca reclame pas mal d'aide de l'os, en fait. Le debugger de perl "simule" ca en refaisant tourner le programme du debut jusqu'au point courant. Ca suppose bien sur que ton programme est "sans effet de bord" au sens large et que l'executer deux fois donnera le meme resultat.
En C, dans un environnement reel, bonne chance: les fichiers et autres appels systeme vont poser de vrais soucis. La seule solution, c'est d'avoir un environnement completement simule, et de prendre des instantanes, d'instruction a instruction: la trace de ton programme se compresse tres bien et on peut appliquer exactement les memes techniques que pour de la video (trames de reference, diff avant/arriere, voire replay localise pour arriver ou on veut). Mais, je le repete, ca ne fonctionne *que* si tu controles totalement l'environnement, memoire + objets exotiques tels les entrees-sorties...
In article <4aae35a7$0$5650$426a74cc@news.free.fr>,
candide <candide@free.invalid> wrote:
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).
Non, gdb ne sait pas vraiment faire... ca reclame pas mal d'aide de l'os,
en fait. Le debugger de perl "simule" ca en refaisant tourner le programme
du debut jusqu'au point courant. Ca suppose bien sur que ton programme
est "sans effet de bord" au sens large et que l'executer deux fois donnera
le meme resultat.
En C, dans un environnement reel, bonne chance: les fichiers et autres
appels systeme vont poser de vrais soucis. La seule solution, c'est d'avoir
un environnement completement simule, et de prendre des instantanes,
d'instruction a instruction: la trace de ton programme se compresse tres bien
et on peut appliquer exactement les memes techniques que pour de la video
(trames de reference, diff avant/arriere, voire replay localise pour arriver
ou on veut). Mais, je le repete, ca ne fonctionne *que* si tu controles
totalement l'environnement, memoire + objets exotiques tels les
entrees-sorties...
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).
Non, gdb ne sait pas vraiment faire... ca reclame pas mal d'aide de l'os, en fait. Le debugger de perl "simule" ca en refaisant tourner le programme du debut jusqu'au point courant. Ca suppose bien sur que ton programme est "sans effet de bord" au sens large et que l'executer deux fois donnera le meme resultat.
En C, dans un environnement reel, bonne chance: les fichiers et autres appels systeme vont poser de vrais soucis. La seule solution, c'est d'avoir un environnement completement simule, et de prendre des instantanes, d'instruction a instruction: la trace de ton programme se compresse tres bien et on peut appliquer exactement les memes techniques que pour de la video (trames de reference, diff avant/arriere, voire replay localise pour arriver ou on veut). Mais, je le repete, ca ne fonctionne *que* si tu controles totalement l'environnement, memoire + objets exotiques tels les entrees-sorties...
Gabriel Dos Reis
Marc Boyer writes:
| 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 ?
À la fin du cours, ou du TD.
| Après un TD sur strcpy, surement pas. Après | les 10 TD + 10 TP + le projet, c'était raisonnable.
C'est déjà trop tard, je pense.
| > 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.
Presque.
| Mais même quand on écrit un programme, | il faut se poser la question des plateformes d'exécution visées.
Oui, mais c'est des questions qu'ils devraient se poser une fois qu'ils savent écrire des programmes !
| Ensuite, le découpage d'un programme en modules implique un travail | de définitions d'interface.
Là tu parles de programmes de taille relativement conséquentes. Le pauvre gars devrait peut être apprendre à écrire de simples programmes d'abord avant de s'occuper de l'organisation. Je pense. Savoir écrire des programmes demande beaucoup de pratique. Apprendre et savoir organiser ses programmes est quelque chose qui demande d'écrire beaucoup de programmes.
Autrement, on a des gars qui se perdent dans des hyper-abstractions et ne finissent jamais leurs programmes (une bibliothèque est un programme non fini) parce qu'ils sont perdus dans des organisations élaborées de modules et d'interfaces.
-- Gaby
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
| 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 ?
À la fin du cours, ou du TD.
| Après un TD sur strcpy, surement pas. Après
| les 10 TD + 10 TP + le projet, c'était raisonnable.
C'est déjà trop tard, je pense.
| > 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.
Presque.
| Mais même quand on écrit un programme,
| il faut se poser la question des plateformes d'exécution visées.
Oui, mais c'est des questions qu'ils devraient se poser une fois qu'ils
savent écrire des programmes !
| Ensuite, le découpage d'un programme en modules implique un travail
| de définitions d'interface.
Là tu parles de programmes de taille relativement conséquentes.
Le pauvre gars devrait peut être apprendre à écrire de simples
programmes d'abord avant de s'occuper de l'organisation. Je pense.
Savoir écrire des programmes demande beaucoup de pratique.
Apprendre et savoir organiser ses programmes est quelque chose qui
demande d'écrire beaucoup de programmes.
Autrement, on a des gars qui se perdent dans des hyper-abstractions et
ne finissent jamais leurs programmes (une bibliothèque est un programme
non fini) parce qu'ils sont perdus dans des organisations élaborées de
modules et d'interfaces.
| 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 ?
À la fin du cours, ou du TD.
| Après un TD sur strcpy, surement pas. Après | les 10 TD + 10 TP + le projet, c'était raisonnable.
C'est déjà trop tard, je pense.
| > 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.
Presque.
| Mais même quand on écrit un programme, | il faut se poser la question des plateformes d'exécution visées.
Oui, mais c'est des questions qu'ils devraient se poser une fois qu'ils savent écrire des programmes !
| Ensuite, le découpage d'un programme en modules implique un travail | de définitions d'interface.
Là tu parles de programmes de taille relativement conséquentes. Le pauvre gars devrait peut être apprendre à écrire de simples programmes d'abord avant de s'occuper de l'organisation. Je pense. Savoir écrire des programmes demande beaucoup de pratique. Apprendre et savoir organiser ses programmes est quelque chose qui demande d'écrire beaucoup de programmes.
Autrement, on a des gars qui se perdent dans des hyper-abstractions et ne finissent jamais leurs programmes (une bibliothèque est un programme non fini) parce qu'ils sont perdus dans des organisations élaborées de modules et d'interfaces.
-- Gaby
Stephane Legras-Decussy
"Marc Boyer" a écrit dans le message de news: h8l7he$4rv$
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
pourtant on constate que les étudiants n'ont *aucun* problème avec les trucs magiques...
pour 99% des étudiants GCC est de la magie pure...
le gars que ça perturbe est probablement surdoué, tu peux l'envoyer en stage direct aux states chez Gabriel :-)
"Marc Boyer" <Marc.Boyer@cert.onera.fr.invalid> a écrit dans le message de
news: h8l7he$4rv$2@news.cict.fr...
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
pourtant on constate que les étudiants n'ont *aucun*
problème avec les trucs magiques...
pour 99% des étudiants GCC est de la magie pure...
le gars que ça perturbe est probablement surdoué, tu peux l'envoyer
en stage direct aux states chez Gabriel :-)
"Marc Boyer" a écrit dans le message de news: h8l7he$4rv$
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
pourtant on constate que les étudiants n'ont *aucun* problème avec les trucs magiques...
pour 99% des étudiants GCC est de la magie pure...
le gars que ça perturbe est probablement surdoué, tu peux l'envoyer en stage direct aux states chez Gabriel :-)
Gabriel Dos Reis
Marc Boyer writes:
| Le 14-09-2009, Gabriel Dos Reis a écrit : | > Marc Boyer writes: | > | > [...] | > | >| Je présentais la ligne de commande "-Wall -pedantic" dans les 10 premiers | >| transparents. Et de même que je refusais de lire un code mal indenté, | >| je refusais de chercher un bug dans un code qui laissait passer des | >| Warning avec -Wall -pedantic. | > | > Pour le premier devoir de maison, je fais savoir que tout devoir rendu | > qui ne compile pas avec "-Wall -O2 -pedantic -Werror" est disqualifié. | | Je suis un rien laxiste, je n'obligeais pas -Werror.
Bah, c'est simple : pour les devoirs et projets que je leur donne, je ne suis certain qu'ils auront à écrire des programmes qui produiront des warnings. Et s'ils en ont, il faudrait qu'ils m'expliquent.
-- Gaby
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
| Le 14-09-2009, Gabriel Dos Reis <gdr@cs.tamu.edu> a écrit :
| > Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
| >
| > [...]
| >
| >| Je présentais la ligne de commande "-Wall -pedantic" dans les 10 premiers
| >| transparents. Et de même que je refusais de lire un code mal indenté,
| >| je refusais de chercher un bug dans un code qui laissait passer des
| >| Warning avec -Wall -pedantic.
| >
| > Pour le premier devoir de maison, je fais savoir que tout devoir rendu
| > qui ne compile pas avec "-Wall -O2 -pedantic -Werror" est disqualifié.
|
| Je suis un rien laxiste, je n'obligeais pas -Werror.
Bah, c'est simple : pour les devoirs et projets que je leur donne, je ne
suis certain qu'ils auront à écrire des programmes qui produiront des
warnings. Et s'ils en ont, il faudrait qu'ils m'expliquent.
| Le 14-09-2009, Gabriel Dos Reis a écrit : | > Marc Boyer writes: | > | > [...] | > | >| Je présentais la ligne de commande "-Wall -pedantic" dans les 10 premiers | >| transparents. Et de même que je refusais de lire un code mal indenté, | >| je refusais de chercher un bug dans un code qui laissait passer des | >| Warning avec -Wall -pedantic. | > | > Pour le premier devoir de maison, je fais savoir que tout devoir rendu | > qui ne compile pas avec "-Wall -O2 -pedantic -Werror" est disqualifié. | | Je suis un rien laxiste, je n'obligeais pas -Werror.
Bah, c'est simple : pour les devoirs et projets que je leur donne, je ne suis certain qu'ils auront à écrire des programmes qui produiront des warnings. Et s'ils en ont, il faudrait qu'ils m'expliquent.
-- Gaby
Gabriel Dos Reis
"Stephane Legras-Decussy" writes:
| "Gabriel Dos Reis" a écrit dans le message de news: | | > http://courses.cs.tamu.edu/gdr/2009.fall-315/syllabus.pdf | > | | ouarf.... la note du projet multipliée par 0.9998^m | (m retard en minutes) .... | | ça rigole pas !
Bah, au moins ils apprendront à faire de l'arithmétique :-)
| et en même temps on a super envie de se marrer... :-D
| "Gabriel Dos Reis" <gdr@cs.tamu.edu> a écrit dans le message de news:
| 87ws41lowp.fsf@gauss.cs.tamu.edu...
| > http://courses.cs.tamu.edu/gdr/2009.fall-315/syllabus.pdf
| >
|
| ouarf.... la note du projet multipliée par 0.9998^m
| (m retard en minutes) ....
|
| ça rigole pas !
Bah, au moins ils apprendront à faire de l'arithmétique :-)
| et en même temps on a super envie de se marrer... :-D
| "Gabriel Dos Reis" a écrit dans le message de news: | | > http://courses.cs.tamu.edu/gdr/2009.fall-315/syllabus.pdf | > | | ouarf.... la note du projet multipliée par 0.9998^m | (m retard en minutes) .... | | ça rigole pas !
Bah, au moins ils apprendront à faire de l'arithmétique :-)
| et en même temps on a super envie de se marrer... :-D
:-)
-- Gaby
Gabriel Dos Reis
Marc Boyer writes:
| Le 14-09-2009, Gabriel Dos Reis a écrit : | > Marc Boyer writes: | >| Le 11-09-2009, Gabriel Dos Reis a écrit : | >| > Marc Boyer writes: | >| > | >| > [...] | >| > | >| >| > Les pointeurs, c'est simple. | >| >| | >| >| Voui, mais ça prend plus d'une heure. | >| > | >| > Ça dépend. | >| > | >| > C'est sûr que si le professeur donne l'impression que c'est compliqué, | >| > les 2/3 des élèves imprimeront que c'est compliqué. | >| | >| Il y a là une contradiction difficile à gérer pour l'enseignant. | >| D'une part, il sait qu'il faut que les étudiannts soient attentifs | >| à ce point, et qu'il les prévienne (à moins d'avoir des étudiants | >| dont l'attention est constante sur tout son cour, ce qui ne m'a | >| jamais été donné). | > | > Dans mon expérience, commencer un cours par « aujourd'hui on va aborder | > un sujet difficile » ne capte l'attention de la majorité des élèves que | > pendans 30 secondes. | | Parce que tu manques de charisme. Chez moi, ça dure presque une minute ;-)
Je fais avec ce que j'ai :-/
| | >| D'autre part, plus on dit que c'est difficile, plus les élèvent | >| impriment que c'est difficile. | >| | >| Quel équilibre ? Je suis preneur de toute solution. | > | > J'ai trouver que moviter ce qu'on va faire (le sujet du cours), | > expliquer comment ces problèmes surviennent avec des exemples concrets | > (mais assez simples pour tenir en 50 min ou 1h15min) a souvent beaucoup | > de chances de retenir leur attention pendant un temps relativement assez | > long. | | 50mn de présentation du pourquoi des pointeurs ?
Non, chaque séance de cours dure 50 min. Donc, j'y case motivation, solution, et exemples de code réels.
-- Gaby
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
| Le 14-09-2009, Gabriel Dos Reis <gdr@cs.tamu.edu> a écrit :
| > Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
| >| Le 11-09-2009, Gabriel Dos Reis <gdr@cs.tamu.edu> a écrit :
| >| > Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
| >| >
| >| > [...]
| >| >
| >| >| > Les pointeurs, c'est simple.
| >| >|
| >| >| Voui, mais ça prend plus d'une heure.
| >| >
| >| > Ça dépend.
| >| >
| >| > C'est sûr que si le professeur donne l'impression que c'est compliqué,
| >| > les 2/3 des élèves imprimeront que c'est compliqué.
| >|
| >| Il y a là une contradiction difficile à gérer pour l'enseignant.
| >| D'une part, il sait qu'il faut que les étudiannts soient attentifs
| >| à ce point, et qu'il les prévienne (à moins d'avoir des étudiants
| >| dont l'attention est constante sur tout son cour, ce qui ne m'a
| >| jamais été donné).
| >
| > Dans mon expérience, commencer un cours par « aujourd'hui on va aborder
| > un sujet difficile » ne capte l'attention de la majorité des élèves que
| > pendans 30 secondes.
|
| Parce que tu manques de charisme. Chez moi, ça dure presque une minute ;-)
Je fais avec ce que j'ai :-/
|
| >| D'autre part, plus on dit que c'est difficile, plus les élèvent
| >| impriment que c'est difficile.
| >|
| >| Quel équilibre ? Je suis preneur de toute solution.
| >
| > J'ai trouver que moviter ce qu'on va faire (le sujet du cours),
| > expliquer comment ces problèmes surviennent avec des exemples concrets
| > (mais assez simples pour tenir en 50 min ou 1h15min) a souvent beaucoup
| > de chances de retenir leur attention pendant un temps relativement assez
| > long.
|
| 50mn de présentation du pourquoi des pointeurs ?
Non, chaque séance de cours dure 50 min. Donc, j'y case motivation,
solution, et exemples de code réels.
| Le 14-09-2009, Gabriel Dos Reis a écrit : | > Marc Boyer writes: | >| Le 11-09-2009, Gabriel Dos Reis a écrit : | >| > Marc Boyer writes: | >| > | >| > [...] | >| > | >| >| > Les pointeurs, c'est simple. | >| >| | >| >| Voui, mais ça prend plus d'une heure. | >| > | >| > Ça dépend. | >| > | >| > C'est sûr que si le professeur donne l'impression que c'est compliqué, | >| > les 2/3 des élèves imprimeront que c'est compliqué. | >| | >| Il y a là une contradiction difficile à gérer pour l'enseignant. | >| D'une part, il sait qu'il faut que les étudiannts soient attentifs | >| à ce point, et qu'il les prévienne (à moins d'avoir des étudiants | >| dont l'attention est constante sur tout son cour, ce qui ne m'a | >| jamais été donné). | > | > Dans mon expérience, commencer un cours par « aujourd'hui on va aborder | > un sujet difficile » ne capte l'attention de la majorité des élèves que | > pendans 30 secondes. | | Parce que tu manques de charisme. Chez moi, ça dure presque une minute ;-)
Je fais avec ce que j'ai :-/
| | >| D'autre part, plus on dit que c'est difficile, plus les élèvent | >| impriment que c'est difficile. | >| | >| Quel équilibre ? Je suis preneur de toute solution. | > | > J'ai trouver que moviter ce qu'on va faire (le sujet du cours), | > expliquer comment ces problèmes surviennent avec des exemples concrets | > (mais assez simples pour tenir en 50 min ou 1h15min) a souvent beaucoup | > de chances de retenir leur attention pendant un temps relativement assez | > long. | | 50mn de présentation du pourquoi des pointeurs ?
Non, chaque séance de cours dure 50 min. Donc, j'y case motivation, solution, et exemples de code réels.
