é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,
Un dégogueur utilisé comme un VCR (arrêt sur image, avance rapide, etc)
Le pas à pas en arrière est rare, bien que ça existe, sur un petit nombre d'instructions s'entend. Mais pas dans gdb sous archi Intel sauf erreur de ma part.
est un bon outil pédagogique, ça fait vivre un programme, dommage que les interfaces soient un peu austères (même DDD).
Eclipse - CDT a une perspective Debug tout à fait convenable. Le problème sous Windows 64bit est de faire fonctionner gdb. Modification et compilation nécessaire.
-- Pierre Maurette
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, bien que ça existe, sur un petit
nombre d'instructions s'entend. Mais pas dans gdb sous archi Intel sauf
erreur de ma part.
est un bon outil pédagogique, ça fait
vivre un programme, dommage que les interfaces soient un peu austères (même
DDD).
Eclipse - CDT a une perspective Debug tout à fait convenable. Le
problème sous Windows 64bit est de faire fonctionner gdb. Modification
et compilation nécessaire.
Un dégogueur utilisé comme un VCR (arrêt sur image, avance rapide, etc)
Le pas à pas en arrière est rare, bien que ça existe, sur un petit nombre d'instructions s'entend. Mais pas dans gdb sous archi Intel sauf erreur de ma part.
est un bon outil pédagogique, ça fait vivre un programme, dommage que les interfaces soient un peu austères (même DDD).
Eclipse - CDT a une perspective Debug tout à fait convenable. Le problème sous Windows 64bit est de faire fonctionner gdb. Modification et compilation nécessaire.
-- Pierre Maurette
espie
In article <4aae1943$0$25120$, candide wrote:
Marc Boyer a écrit :
Mais comme tu le disais, ça dépend si on peut s'appuyer sur une connaissance des étudiants de ce qu'est la mémoire. Si ça n'a pas été fait, faut en faire un peu. C'est plus facile d'enseigner le C après 30h d'architecure des ordinateurs.
Tu veux dire de t'appuyer sur des connaissances d'architecture pour enseigner le C ? Ça se discute, disons que ça dépend de ton objectif mais en ce qui concerne mes propres apprentissages, j'essaye d'éviter les empilements. Mais il est tout à fait possible de s'en passer. La mémoire est une abstraction et elle peut rester telle quand on enseigne le C. Probablement que dans des usages avancés voire spécialisés, des connaissances d'archi (et d'assembleur) peuvent être instructives voire utiles. Un dégogueur utilisé comme un VCR (arrêt sur image, avance rapide, etc) est un bon outil pédagogique, ça fait vivre un programme, dommage que les interfaces soient un peu austères (même DDD).
Je suis un peu pessimiste sur le coup. Ce que tu decris ne marche pas avec toutes les populations d'etudiants. Pour que la memoire reste une abstraction, il faut qu'ils aient de bonnes capacites d'abstraction, justement. Meme avec toute la bonne volonte du monde, j'ai toujours un mal fou a faire rentrer la notion de portabilite. La notion d'undefined behavior est tres difficile a integrer.
L'exemple standard, c'est les etudiants qui ne tapent pas le -O2 -Wall du gcc (parce que c'est trop long) et qui me pondent du code qui "tombe en marche" (grace a la superbe idee de gcc d'initialiser a 0 les variables locales en -O0), et a qui j'ai un mal fou a expliquer que leur programme est buggue jusqu'a l'os...
Donc, j'ai du code buggue, et des questions, et je suis bien oblige d'expliquer que le code "tape" a cote, ce qu'une fonction avec pas le bon nombre de parametres va faire, et tout et tout. En fait, c'est tres dommage que, sur les compilo modernes, le mode par defaut ne soit pas hyper-strict. Genre -Wall -O1 -Werror... mais pour ca, faudrait que gcc sache reconnaitre les faux positifs, et separer les "warnings" des "warnings qui devaient etre des erreurs" dans 100% des cas, quitte a etre biaise dans le sens "laisser passer des warnings", mais bon.
In article <4aae1943$0$25120$426a74cc@news.free.fr>,
candide <candide@free.invalid> wrote:
Marc Boyer a écrit :
Mais comme tu le disais, ça dépend si on peut s'appuyer sur une
connaissance des étudiants de ce qu'est la mémoire.
Si ça n'a pas été fait, faut en faire un peu.
C'est plus facile d'enseigner le C après 30h d'architecure des
ordinateurs.
Tu veux dire de t'appuyer sur des connaissances d'architecture pour enseigner le
C ? Ça se discute, disons que ça dépend de ton objectif mais en ce qui concerne
mes propres apprentissages, j'essaye d'éviter les empilements. Mais il est tout
à fait possible de s'en passer. La mémoire est une abstraction et elle peut
rester telle quand on enseigne le C. Probablement que dans des usages avancés
voire spécialisés, des connaissances d'archi (et d'assembleur) peuvent être
instructives voire utiles. Un dégogueur utilisé comme un VCR (arrêt sur image,
avance rapide, etc) est un bon outil pédagogique, ça fait vivre un programme,
dommage que les interfaces soient un peu austères (même DDD).
Je suis un peu pessimiste sur le coup. Ce que tu decris ne marche pas avec
toutes les populations d'etudiants. Pour que la memoire reste une abstraction,
il faut qu'ils aient de bonnes capacites d'abstraction, justement. Meme
avec toute la bonne volonte du monde, j'ai toujours un mal fou a faire
rentrer la notion de portabilite. La notion d'undefined behavior est tres
difficile a integrer.
L'exemple standard, c'est les etudiants qui ne tapent pas le -O2 -Wall du gcc
(parce que c'est trop long) et qui me pondent du code qui "tombe en marche"
(grace a la superbe idee de gcc d'initialiser a 0 les variables locales
en -O0), et a qui j'ai un mal fou a expliquer que leur programme est buggue
jusqu'a l'os...
Donc, j'ai du code buggue, et des questions, et je suis bien oblige d'expliquer
que le code "tape" a cote, ce qu'une fonction avec pas le bon nombre de
parametres va faire, et tout et tout. En fait, c'est tres dommage que,
sur les compilo modernes, le mode par defaut ne soit pas hyper-strict.
Genre -Wall -O1 -Werror... mais pour ca, faudrait que gcc sache reconnaitre
les faux positifs, et separer les "warnings" des "warnings qui devaient
etre des erreurs" dans 100% des cas, quitte a etre biaise dans le sens
"laisser passer des warnings", mais bon.
Mais comme tu le disais, ça dépend si on peut s'appuyer sur une connaissance des étudiants de ce qu'est la mémoire. Si ça n'a pas été fait, faut en faire un peu. C'est plus facile d'enseigner le C après 30h d'architecure des ordinateurs.
Tu veux dire de t'appuyer sur des connaissances d'architecture pour enseigner le C ? Ça se discute, disons que ça dépend de ton objectif mais en ce qui concerne mes propres apprentissages, j'essaye d'éviter les empilements. Mais il est tout à fait possible de s'en passer. La mémoire est une abstraction et elle peut rester telle quand on enseigne le C. Probablement que dans des usages avancés voire spécialisés, des connaissances d'archi (et d'assembleur) peuvent être instructives voire utiles. Un dégogueur utilisé comme un VCR (arrêt sur image, avance rapide, etc) est un bon outil pédagogique, ça fait vivre un programme, dommage que les interfaces soient un peu austères (même DDD).
Je suis un peu pessimiste sur le coup. Ce que tu decris ne marche pas avec toutes les populations d'etudiants. Pour que la memoire reste une abstraction, il faut qu'ils aient de bonnes capacites d'abstraction, justement. Meme avec toute la bonne volonte du monde, j'ai toujours un mal fou a faire rentrer la notion de portabilite. La notion d'undefined behavior est tres difficile a integrer.
L'exemple standard, c'est les etudiants qui ne tapent pas le -O2 -Wall du gcc (parce que c'est trop long) et qui me pondent du code qui "tombe en marche" (grace a la superbe idee de gcc d'initialiser a 0 les variables locales en -O0), et a qui j'ai un mal fou a expliquer que leur programme est buggue jusqu'a l'os...
Donc, j'ai du code buggue, et des questions, et je suis bien oblige d'expliquer que le code "tape" a cote, ce qu'une fonction avec pas le bon nombre de parametres va faire, et tout et tout. En fait, c'est tres dommage que, sur les compilo modernes, le mode par defaut ne soit pas hyper-strict. Genre -Wall -O1 -Werror... mais pour ca, faudrait que gcc sache reconnaitre les faux positifs, et separer les "warnings" des "warnings qui devaient etre des erreurs" dans 100% des cas, quitte a etre biaise dans le sens "laisser passer des warnings", mais bon.
espie
In article <4aae1b2a$0$32766$, candide wrote:
Marc Espie a écrit :
de "cours cours" ou avec TD et TP ?
Cours-cours,
Madre mia ! Vous leur faites 30 heures de cours sans le moindre TP ????? J'espère pour eux que tu fais tes cours sur video-projecteur avec gcc dans tes valises.
Si, ils passent quand meme quelques heures en salle machine avec moi derriere, pour les lancer (genre 3 ou 6h), mais pour le reste, c'est a eux d'essayer de faire des trucs et de revenir avec des questions au cours suivant.
Faut dire que j'ai suffisamment d'experience pour pouvoir t'inventer du listing sans faute au tableau. Comme tu as pu le voir ici, il y a des points obscurs du C que je ne maitrise pas sans relire la norme, mais je n'arrive jamais jusqu'a ces points obscurs en cours. Il y a aussi des tonnes de trucs que je peux faire sur un tableau que je ne peux pas faire en salle machine, en vrai (montrer rapidement les diverses facons d'ecrire la meme chose, dire lesquelles posent probleme, faire de la reecriture automatique sur du code). Mais en general, le cours est bien la comme reference: ils ont des pointeurs sur de la litterature externe, et des exemples, et normalement, vers une 20aine d'heures, on arrete d'ecrire des trucs a partir de rien, et on passe sur du code existant reel... ce qui est toujours tres drole au depart (et je passe sur projo avec ma machine et des listings existants).
In article <4aae1b2a$0$32766$426a34cc@news.free.fr>,
candide <candide@free.invalid> wrote:
Marc Espie a écrit :
de "cours cours" ou avec TD et TP ?
Cours-cours,
Madre mia ! Vous leur faites 30 heures de cours sans le moindre TP ?????
J'espère pour eux que tu fais tes cours sur video-projecteur avec gcc dans tes
valises.
Si, ils passent quand meme quelques heures en salle machine avec moi derriere,
pour les lancer (genre 3 ou 6h), mais pour le reste, c'est a eux d'essayer
de faire des trucs et de revenir avec des questions au cours suivant.
Faut dire que j'ai suffisamment d'experience pour pouvoir t'inventer
du listing sans faute au tableau. Comme tu as pu le voir ici, il y a des
points obscurs du C que je ne maitrise pas sans relire la norme, mais je
n'arrive jamais jusqu'a ces points obscurs en cours. Il y a aussi des
tonnes de trucs que je peux faire sur un tableau que je ne peux pas faire
en salle machine, en vrai (montrer rapidement les diverses facons d'ecrire
la meme chose, dire lesquelles posent probleme, faire de la reecriture
automatique sur du code). Mais en general, le cours est bien la comme
reference: ils ont des pointeurs sur de la litterature externe, et des
exemples, et normalement, vers une 20aine d'heures, on arrete d'ecrire des
trucs a partir de rien, et on passe sur du code existant reel... ce qui
est toujours tres drole au depart (et je passe sur projo avec ma machine
et des listings existants).
Madre mia ! Vous leur faites 30 heures de cours sans le moindre TP ????? J'espère pour eux que tu fais tes cours sur video-projecteur avec gcc dans tes valises.
Si, ils passent quand meme quelques heures en salle machine avec moi derriere, pour les lancer (genre 3 ou 6h), mais pour le reste, c'est a eux d'essayer de faire des trucs et de revenir avec des questions au cours suivant.
Faut dire que j'ai suffisamment d'experience pour pouvoir t'inventer du listing sans faute au tableau. Comme tu as pu le voir ici, il y a des points obscurs du C que je ne maitrise pas sans relire la norme, mais je n'arrive jamais jusqu'a ces points obscurs en cours. Il y a aussi des tonnes de trucs que je peux faire sur un tableau que je ne peux pas faire en salle machine, en vrai (montrer rapidement les diverses facons d'ecrire la meme chose, dire lesquelles posent probleme, faire de la reecriture automatique sur du code). Mais en general, le cours est bien la comme reference: ils ont des pointeurs sur de la litterature externe, et des exemples, et normalement, vers une 20aine d'heures, on arrete d'ecrire des trucs a partir de rien, et on passe sur du code existant reel... ce qui est toujours tres drole au depart (et je passe sur projo avec ma machine et des listings existants).
Un des trucs bien de l'Ecole ou je suis, c'est l'organisation de la salle machines: il n'y a que des PC vides, sans disque. On prete/vend aux etudiants un disque en rack, en debut d'annee, et ils sont de fait admin sur leur machine. Le boulot de l'equipe systeme, c'est de leur fournir une installation "decente" en image reseau (une combo linux + windows, en l'occurrence), et apres les etudiants sont libres d'installer ce qu'ils veulent.
Ca evite tous les problemes de latence au niveau de l'equipe systeme, meme si les etudiants rament un peu a installer des packages supplementaires au debut...
Evidemment, ca suppose qu'on va former des "vrais informaticiens", des gus qui auront quelques notions d'un peu tout et qui ne seront pas completement largues lorsqu'on leur proposera d'administrer leur propre poste.
In article <h8l7he$4rv$2@news.cict.fr>,
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> wrote:
Un des trucs bien de l'Ecole ou je suis, c'est l'organisation de la salle
machines: il n'y a que des PC vides, sans disque. On prete/vend aux etudiants
un disque en rack, en debut d'annee, et ils sont de fait admin sur leur
machine. Le boulot de l'equipe systeme, c'est de leur fournir une
installation "decente" en image reseau (une combo linux + windows, en
l'occurrence), et apres les etudiants sont libres d'installer ce qu'ils
veulent.
Ca evite tous les problemes de latence au niveau de l'equipe systeme, meme
si les etudiants rament un peu a installer des packages supplementaires
au debut...
Evidemment, ca suppose qu'on va former des "vrais informaticiens", des gus
qui auront quelques notions d'un peu tout et qui ne seront pas completement
largues lorsqu'on leur proposera d'administrer leur propre poste.
Un des trucs bien de l'Ecole ou je suis, c'est l'organisation de la salle machines: il n'y a que des PC vides, sans disque. On prete/vend aux etudiants un disque en rack, en debut d'annee, et ils sont de fait admin sur leur machine. Le boulot de l'equipe systeme, c'est de leur fournir une installation "decente" en image reseau (une combo linux + windows, en l'occurrence), et apres les etudiants sont libres d'installer ce qu'ils veulent.
Ca evite tous les problemes de latence au niveau de l'equipe systeme, meme si les etudiants rament un peu a installer des packages supplementaires au debut...
Evidemment, ca suppose qu'on va former des "vrais informaticiens", des gus qui auront quelques notions d'un peu tout et qui ne seront pas completement largues lorsqu'on leur proposera d'administrer leur propre poste.
Gabriel Dos Reis
Marc Boyer writes:
| Le 11-09-2009, Gabriel Dos Reis a écrit : | > Marc Boyer writes: | > | >| Les pointeurs sont incontournables (ou très difficilement | >| contournable) pour: | > | > La majorité de ceux qui font du Java n'ont jamais entendu parler de | > pointeurs -- ou alors, ils savent que c'est un truc sale que les gens | > peu évolués manipulent. | | J'avoue que comme dans notre formation, C venait avant Java, | je n'ai pas vraiment connu ce problème.
Ici, on a des freshmen qui arrivent avec des rudiments de Java (vraiment des rudiments...). Pour eux, le C est un choc. Du coup, on leur enseigne autre chose :-)
http://www.research.att.com/~bs/software.pdf
| Reste qu'on a toujours les mêmes problèmes avec les | mêmes notions: | - partage d'objet | - allocation dynamique | - durée de vie
-- Gaby
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 sont incontournables (ou très difficilement
| >| contournable) pour:
| >
| > La majorité de ceux qui font du Java n'ont jamais entendu parler de
| > pointeurs -- ou alors, ils savent que c'est un truc sale que les gens
| > peu évolués manipulent.
|
| J'avoue que comme dans notre formation, C venait avant Java,
| je n'ai pas vraiment connu ce problème.
Ici, on a des freshmen qui arrivent avec des rudiments de Java (vraiment
des rudiments...). Pour eux, le C est un choc. Du coup, on leur
enseigne autre chose :-)
http://www.research.att.com/~bs/software.pdf
| Reste qu'on a toujours les mêmes problèmes avec les
| mêmes notions:
| - partage d'objet
| - allocation dynamique
| - durée de vie
| Le 11-09-2009, Gabriel Dos Reis a écrit : | > Marc Boyer writes: | > | >| Les pointeurs sont incontournables (ou très difficilement | >| contournable) pour: | > | > La majorité de ceux qui font du Java n'ont jamais entendu parler de | > pointeurs -- ou alors, ils savent que c'est un truc sale que les gens | > peu évolués manipulent. | | J'avoue que comme dans notre formation, C venait avant Java, | je n'ai pas vraiment connu ce problème.
Ici, on a des freshmen qui arrivent avec des rudiments de Java (vraiment des rudiments...). Pour eux, le C est un choc. Du coup, on leur enseigne autre chose :-)
http://www.research.att.com/~bs/software.pdf
| Reste qu'on a toujours les mêmes problèmes avec les | mêmes notions: | - partage d'objet | - allocation dynamique | - durée de vie
-- Gaby
espie
In article , -ed- wrote:
On 13 sep, 13:17, candide wrote:
C'est quoi la question _précise_ ? Si c'est afficher la succession des
éléments
d'un tableau d'entiers dont la longueur est donnée en paramètre de la
fonction,
aucun problème (et tu le sais bien, cf. ton post de 10:57) :
#include <stdio.h>
void afficher(int t[], int n) {
Pas l'ombre d'un pointeur ici, c'est complètement transparent pour
l'utilisateur
Euh, 't' est très précisément un pointeur, même si la syntaxe int t[] est différente de int *t, la finalité est la même... En tout cas, t *n'est pas* un tableau...
... et ca met parfaitement en evidence *le* probleme central des pointeurs/references, qui est le probleme d'identite des objets non scalaires... va-t-en expliquer que les parametres sont passes par valeur en C, sauf pour les tableaux, pour lesquels c'est special, et sans evoquer la notion de pointeur. Des que tu as des etudiants qui veulent des explications "precises", si tu veux absolument eviter les pointeurs, tu te retrouves a devoir inventer des regles tres arbitraires pour expliquer cela...
In article <f934395e-01a8-43be-b73a-b01ff1554a17@d4g2000vbm.googlegroups.com>,
-ed- <emmanuel.delahaye@gmail.com> wrote:
On 13 sep, 13:17, candide <cand...@free.invalid> wrote:
C'est quoi la question _précise_ ? Si c'est afficher la succession des
éléments
d'un tableau d'entiers dont la longueur est donnée en paramètre de la
fonction,
aucun problème (et tu le sais bien, cf. ton post de 10:57) :
#include <stdio.h>
void afficher(int t[], int n)
{
Pas l'ombre d'un pointeur ici, c'est complètement transparent pour
l'utilisateur
Euh, 't' est très précisément un pointeur, même si la syntaxe int t[]
est différente de int *t, la finalité est la même... En tout cas, t
*n'est pas* un tableau...
... et ca met parfaitement en evidence *le* probleme central des
pointeurs/references, qui est le probleme d'identite des objets non
scalaires... va-t-en expliquer que les parametres sont passes par valeur
en C, sauf pour les tableaux, pour lesquels c'est special, et sans evoquer
la notion de pointeur. Des que tu as des etudiants qui veulent des
explications "precises", si tu veux absolument eviter les pointeurs, tu
te retrouves a devoir inventer des regles tres arbitraires pour expliquer
cela...
C'est quoi la question _précise_ ? Si c'est afficher la succession des
éléments
d'un tableau d'entiers dont la longueur est donnée en paramètre de la
fonction,
aucun problème (et tu le sais bien, cf. ton post de 10:57) :
#include <stdio.h>
void afficher(int t[], int n) {
Pas l'ombre d'un pointeur ici, c'est complètement transparent pour
l'utilisateur
Euh, 't' est très précisément un pointeur, même si la syntaxe int t[] est différente de int *t, la finalité est la même... En tout cas, t *n'est pas* un tableau...
... et ca met parfaitement en evidence *le* probleme central des pointeurs/references, qui est le probleme d'identite des objets non scalaires... va-t-en expliquer que les parametres sont passes par valeur en C, sauf pour les tableaux, pour lesquels c'est special, et sans evoquer la notion de pointeur. Des que tu as des etudiants qui veulent des explications "precises", si tu veux absolument eviter les pointeurs, tu te retrouves a devoir inventer des regles tres arbitraires pour expliquer cela...
Gabriel Dos Reis
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.
| 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.
-- Gaby
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.
| 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.
| 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.
| 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.
-- Gaby
candide
-ed- a écrit :
Euh, 't' est très précisément un pointeur, même si la syntaxe int t[] est différente de int *t, la finalité est la même... En tout cas, t *n'est pas* un tableau...
Je sais bien même si ta formulation pourrait se discuter, extrait de K&R2 :
----------------------------------------- In getline, the arguments are declared by the line
int getline(char s[], int lim);
which specifies that the first argument, s, is an array, and the second, lim, is an integer. -----------------------------------------
Mais la question n'est pas là, le pointeur est transparent pour l'utilisateur, c'est tout ce qui compte. Il suffit jusque que l'utilisateur sache qu'il peut modifier le contenu du tableau passé en paramètre depuis sa fonction, le pourquoi du comment, on s'en fout, dans un premier temps du moins. Il me semblait que t'avais compris la différence qu'il peut y avoir entre une interface et une implémentation, les cordonniers ....
-ed- a écrit :
Euh, 't' est très précisément un pointeur, même si la syntaxe int t[]
est différente de int *t, la finalité est la même... En tout cas, t
*n'est pas* un tableau...
Je sais bien même si ta formulation pourrait se discuter, extrait de K&R2 :
-----------------------------------------
In getline, the arguments are declared by the line
int getline(char s[], int lim);
which specifies that the first argument, s, is an array, and the second, lim, is
an integer.
-----------------------------------------
Mais la question n'est pas là, le pointeur est transparent pour l'utilisateur,
c'est tout ce qui compte. Il suffit jusque que l'utilisateur sache qu'il peut
modifier le contenu du tableau passé en paramètre depuis sa fonction, le
pourquoi du comment, on s'en fout, dans un premier temps du moins. Il me
semblait que t'avais compris la différence qu'il peut y avoir entre une
interface et une implémentation, les cordonniers ....
Euh, 't' est très précisément un pointeur, même si la syntaxe int t[] est différente de int *t, la finalité est la même... En tout cas, t *n'est pas* un tableau...
Je sais bien même si ta formulation pourrait se discuter, extrait de K&R2 :
----------------------------------------- In getline, the arguments are declared by the line
int getline(char s[], int lim);
which specifies that the first argument, s, is an array, and the second, lim, is an integer. -----------------------------------------
Mais la question n'est pas là, le pointeur est transparent pour l'utilisateur, c'est tout ce qui compte. Il suffit jusque que l'utilisateur sache qu'il peut modifier le contenu du tableau passé en paramètre depuis sa fonction, le pourquoi du comment, on s'en fout, dans un premier temps du moins. Il me semblait que t'avais compris la différence qu'il peut y avoir entre une interface et une implémentation, les cordonniers ....
Gabriel Dos Reis
Manuel Pégourié-Gonnard <mpg+ writes:
| Marc Boyer scripsit: | | > Le 11-09-2009, Gabriel Dos Reis a écrit : | >> 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é). | > 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. | > | Je suis loin de pouvoir proposer une solution, mais j'aimerais apporter | quelques arguments en faveur du « dire que c'est difficile ». | D'une part, certains étudiants peuvent avoir tendance à se décourager, | voire décrocher du reste du cours, si ils n'y arrivent pas alors qu'on | leur répète que c'est facile.
J'évite de leur dire que « c'est facile » ou que « c'est difficile ». Dans les deux cas, il y a de fortes chances de heurter le progrès ou l'attention de l'une ou de l'autre. Je concentre mon temps pour expliquer quels problèmes on essaie de résoudre et pourquoi. Souvent si le problème est bien compris, alors la présentation de la solution est plus facile à avaler.
-- Gaby
Manuel Pégourié-Gonnard <mpg+news@elzevir.fr> writes:
| Marc Boyer scripsit:
|
| > Le 11-09-2009, Gabriel Dos Reis <gdr@cs.tamu.edu> a écrit :
| >> 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é).
| > 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.
| >
| Je suis loin de pouvoir proposer une solution, mais j'aimerais apporter
| quelques arguments en faveur du « dire que c'est difficile ».
| D'une part, certains étudiants peuvent avoir tendance à se décourager,
| voire décrocher du reste du cours, si ils n'y arrivent pas alors qu'on
| leur répète que c'est facile.
J'évite de leur dire que « c'est facile » ou que « c'est difficile ».
Dans les deux cas, il y a de fortes chances de heurter le progrès
ou l'attention de l'une ou de l'autre. Je concentre mon temps pour
expliquer quels problèmes on essaie de résoudre et pourquoi. Souvent si
le problème est bien compris, alors la présentation de la solution est
plus facile à avaler.
| Marc Boyer scripsit: | | > Le 11-09-2009, Gabriel Dos Reis a écrit : | >> 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é). | > 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. | > | Je suis loin de pouvoir proposer une solution, mais j'aimerais apporter | quelques arguments en faveur du « dire que c'est difficile ». | D'une part, certains étudiants peuvent avoir tendance à se décourager, | voire décrocher du reste du cours, si ils n'y arrivent pas alors qu'on | leur répète que c'est facile.
J'évite de leur dire que « c'est facile » ou que « c'est difficile ». Dans les deux cas, il y a de fortes chances de heurter le progrès ou l'attention de l'une ou de l'autre. Je concentre mon temps pour expliquer quels problèmes on essaie de résoudre et pourquoi. Souvent si le problème est bien compris, alors la présentation de la solution est plus facile à avaler.
-- Gaby
Gabriel Dos Reis
(Marc Espie) writes:
[...]
| Non, par contre, comprendre ce qu'on peut faire avec, pourquoi c'est | indispensable, montrer les idiomes vitaux aux etudiants, ca c'est | complique.
C'est certainement compliqué, mais je crois que c'est le but d'un cours de *programmation* en C. Le professeur peut faire l'économie de sa terreur pendant qu'il est en train de confronter cette délicatesse :-)
-- Gaby
espie@lain.home (Marc Espie) writes:
[...]
| Non, par contre, comprendre ce qu'on peut faire avec, pourquoi c'est
| indispensable, montrer les idiomes vitaux aux etudiants, ca c'est
| complique.
C'est certainement compliqué, mais je crois que c'est le but d'un cours
de *programmation* en C. Le professeur peut faire l'économie de sa
terreur pendant qu'il est en train de confronter cette délicatesse :-)
| Non, par contre, comprendre ce qu'on peut faire avec, pourquoi c'est | indispensable, montrer les idiomes vitaux aux etudiants, ca c'est | complique.
C'est certainement compliqué, mais je crois que c'est le but d'un cours de *programmation* en C. Le professeur peut faire l'économie de sa terreur pendant qu'il est en train de confronter cette délicatesse :-)
