Différence de résultat entre compilateurs

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

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 .

Possible.

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.

Des paquets portables SunOS / Linux / Win ?
Et oui, parfois, on ne sait pas quand on prépare les sujets
dans quelle salle auront lieu les TP.

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).

Le but de l'enseignant, oui. Mais l'étudiant... Quand il fait
*quasiment* comme tu as fais, et que ça marche pas...
Franchement, mon expérience de GUI (en Java), c'est que les étudians
essaye de faire des choses un peu différentes de ce que tu as présentés,
et qu'ils sont *très* imaginatifs, et j'ai souvent perdu pas mal
de temps avec des lib mal initialités, ou initialisées deux fois,
ou des mélanges de paradigmes...

- 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.

Et ben, je sais pas faire. Ou disons que j'y perd pas mal de temps.

- 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.

Ben, oui, c'est mon problème.

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).

Oui, donc aucun intérêt d'utiliser le C (sauf s'ils savent déjà coder en C).

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).

Ca permet de discriminer ;-)
Je ne vois pas bien l'intérêt du C pour ce type de formations, mais bon,
je n'ai peut-être pas toutes les cartes en main...
On me souffle que parfois, il y a un prof qui a appris à coder tout seul
en C en 1990, qu'il considère que le C n'est pas l'essentiel du cours, et
que de toute façon, personne ne comprend rien à son cours donc personne
ne le remettra en cause, et que les choses ne changerons que quand il
partira à la retraite et qu'on embauchera un jeune qui a apris avec perl.
Mais peut-être que ce sont de mauvaises langues...

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" <Marc.Boyer@cert.onera.fr.invalid> a écrit dans le message de
news: h8ksqf$a1$2@news.cict.fr...

Bien sûr. Déjà, les types, en 1h...

où est la difficulté ? y'en a une poignée avec leur plage
autorisée... c'est intuitif....

Et tu cases où les opérateurs et les structures de controle ?

après... les structures de contrôle c'est vraiment
simple (s'attarder sur continue peut être) ...

ensuite les structures... et en dernier les pointeurs
de fonction... là de toute façon ils pigent rien...


l'organisation de projet par contre ça passe très mal,
en DUT, licence, maitrise, DEA orienté electronique
d'où je viens, c'est (c'était) même pas abordé...

Le 14-09-2009, Gabriel Dos Reis <gdr@cs.tamu.edu> a écrit :

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 ?

Ca dépend aussi des moyens que tu as (nb d'heures alloués au cours),
nombre d'intervenants, etc...

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 Espie a écrit :

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.

Ce n'est pas mon avis. Bien sûr si tu parles abstraitement pour décrire des
choses abstraites... Je ne crois pas vraiemnt à cette histoire de "faculté
d'abstraction" comme si ça existait intrinsèquement. La succession des nombres
entiers est une abstraction quand je pense 3 je ne pense pas forcément 3 fleurs,
3 lettres, etc. Pratiquement tout le monde comprend la notion de nombre. Ou
d'infini. L'infini est une abstraction. Ce modèle se construit par des suites
d'instances, dans un contexte d'expérimentation personnelle : le vide stellaire,
les temps anciens, le microscope, le télescope, etc.

Donc, ce qu'il faut c'est des instances. Et un débogueur (par exemple) permet
d'instancier ton programme. Ça rend tangible, le fameux "passage par valeur"
(expression qui m'est resté longtemps hermétique) devient très naturel.

Meme
avec toute la bonne volonte du monde, j'ai toujours un mal fou a faire
rentrer la notion de portabilite.

Oui mais ça c'est encore autre chose.

La notion d'undefined behavior est tres
difficile a integrer.

Personnellement, je n'ai pas encore vraiment bien compris ce que c'était. Oui,
j'ai bien lu la définition de la Norme, la liste donnée en annexe J, que ça peut
déclencher une guerre nucléaire et tout et tout mais je _sens_ que je n'ai pas
encore _perçu_ tous les contours de cette notion (et d'ailleurs, je ne serais
pas étonné qu'au bout du compte, elle soit entourée d'un certain flou).

L'exemple standard, c'est les etudiants qui ne tapent pas le -O2 -Wall du gcc
(parce que c'est trop long)

Je les comprends un peu. Savent pas utiliser des alias ?

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...

Tiens c'est amusant ce que tu viens de citer car j'ai découvert cette
possibilité par hasard tout-à-l'heure. J'avais un code sur un forum (écrit par
quelqu'un que je sais pourtant être un étudiant de L3 ou M1 d'informatique) et
qui par mégarde sans doute n'a pas initialisé une variable locale. Je lui ai dit
: "tu as un gros warning à corriger" et il me dit que malgré les options -Wall
-pedantic, il n'a aucun warning. C'est là que j'ai compris que mon -O2 allumait
le warning. Tu vois, ça c'est absolument pas normal que dans les cours (in vivo
ou livresques ) qui se veulent un peu complet, tu n'aies pas ce genre
d'information en fait basique. Ainsi, on récupère les infos de manière fortuite
et c'est aussi pour ça que la maitrise du C est si longue, c'est une question de
conception et d'organisation de la documentation.

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...

Pour le coup, je trouve que compiler avec -Wextra -Wall -std=cx9 est bien
suffisant avec obligation du 0 error 0 warning


Et puis la nature des erreurs (syntaxe, de compilation, d'exécution, de link, de
non conformité avec le résulat attendu, etc) , c'est une notion pas du tout
évidente à comprendre.

In article <874or5ln1n.fsf@gauss.cs.tamu.edu>,
Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:

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.

Il y a un juste milieu. Apprendre a discerner qu'on utilise toujours les
memes operations, et donc qu'il faut faire les fonctions qui vont bien,
c'est indispensable. Pour leur eviter de trop abstraire, je leur montre
ce que ca peut donner (et je leur interdis certains outils, en leur expliquant
que c'est pour bien plus tard, quand ils seront grands. Plus precisement:
- pas le droit a typedef, sauf pour les pointeurs de fonction. Si c'est
complique, c'est qu'ils ont mal fait leur boulot.
- pas le droit a #ifdef
- pas le droit aux macros pour autre chose que les constantes.
- pas le droit aux fichiers d'entetes imbriques. Tout mettre a plat au
depart)

dans tous les cas ou ils finissent par tomber sur des cas ou "ca serait
bien", j'essaie de leur expliquer que c'est un ECHEC de conception, ou le
developpeur n'a pas reussi a faire assez simple (et de mon point de vue,
on en trouve meme dans la bibliotheque standard, FILE * est une grosse
connerie, a mon avis).

Je mets de plus en plus l'accent sur des techniques qui sont peu enseignees
ailleurs, qui sont des techniques de refactorisation: ecrire une maquette
relativement vite, relativement mal. Des que des elements communs se
degagent, apprendre a reconnaitre et extraire la fonction qui sommeillent.
Allie aux techniques de transformation de code (equivalence while/for, sortir
une variable d'une boucle, introduire un temporaire).

Generalement, en expliquant aux etudiants que, si c'est automatique, ben un
bon compilo saura faire, donc qu'ils doivent privilegier clarte et
simplicite et laisser le compilo faire son boulot.


Si on arrive assez loin, je peux finir par expliquer les problemes de
portabilite d'une archi a l'autre pour certains aspects de programmation
bas niveau et d'efficacite, les cas ou typedef ou #ifdef deviennent
necessaires, et les tres rares cas ou les macros servent (avec l'avenement
de inline, de moins en moins, sauf environnement de travail antique et
hostile). Ca se termine le plus souvent sur la notion que, lorsqu'on
en arrive a ce niveau de redefinition du langage, on serait
generalement mieux a faire du C++ a la place (sauf aversion profonde au
langage allie a un etat de folie avancee, style "je vais refaire mon
oriente-objet a la main avec le preprocesseur, toute ressemblance avec
des contributeurs frequents du newsgroup n'etant absolument pas fortuite
ni laissee au hasard).

Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:

[...]

| que de toute façon, personne ne comprend rien à son cours donc personne
| ne le remettra en cause,

Intéressant. Ici, si personne ne comprend ton cours, t'as des soucis :
les élèves évaluent ton cours à la fin du semestre et l'administration
tient compte du retour global en ce qui concerne ton avancement et
autres compensations (i.e. Teaching Excellence Award, etc.)

-- Gaby

In article <4aae3d0b$0$31046$426a74cc@news.free.fr>,
candide <candide@free.invalid> wrote:

Marc Espie a écrit :

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.

Ce n'est pas mon avis. Bien sûr si tu parles abstraitement pour décrire des
choses abstraites... Je ne crois pas vraiemnt à cette histoire de "faculté
d'abstraction" comme si ça existait intrinsèquement. La succession des nombres
entiers est une abstraction quand je pense 3 je ne pense pas forcément 3 fleurs,
3 lettres, etc. Pratiquement tout le monde comprend la notion de nombre. Ou
d'infini. L'infini est une abstraction. Ce modèle se construit par des suites

Non, tout le monde ne comprend pas la notion d'infini. Ca n'est vraiment
pas simple. Si c'etait simple, il n'y aurait pas eu de recherche active
en logique sur le sujet jusqu'a... tres recemment.
- theorie des ensembles
- theorie des categories
- theorie des modeles
- arithmetique non standard
- calculabilite

5 domaines de la logique (au sens large) qui ont directement a voir avec
la notion d'infini... et qui etaient encore tres actifs lorsque j'ai fait
mes etudes.

Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:

| Le 14-09-2009, Gabriel Dos Reis <gdr@cs.tamu.edu> a écrit :
| > 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 ?
|
| Ca dépend aussi des moyens que tu as (nb d'heures alloués au cours),
| nombre d'intervenants, etc...

Grosso modo, j'ai 20 séances de cours de 50min chacune -- ce qui fait
moins que tes 20 heures de cours.

Les étudiants ont lab work 2 fois 50 min par semaine (j'ai un chargé de
TD, mais j'insiste à assister à chaque fois que je peux.)


-- Gaby

candide <candide@free.invalid> writes:


[...]

| : "tu as un gros warning à corriger" et il me dit que malgré les options -Wall
| -pedantic, il n'a aucun warning. C'est là que j'ai compris que mon -O2 allumait
| le warning.

Oui, c'est pour cela que j'inclus '-O2' dans les flags que je demane aux
étudiants.

-- Gaby

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

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.

Pas chez moi. Surtout en informatique. Le contexte est déterminant.
On ne code pas de la même façon un micro-controleur de machine à laver,
les commandes de vol d'un missile et une appli WEB.

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.

Non, je pense que nous serons un certains nombre à dire que les cours
de C "en général", ne sont pas bien bons.

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.

C'est surtout qu'il est très utilisé par "orienté objet".

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.

#include <stdio.h>
int* f(void) {
int i= 4;
puts("f()");
return &i;
}

void g(void) {
int j= 34;
puts("g()");
}

int main(void)
{
/* déclarations ... */
int *x = f();
printf("x=%dn",*x);
g();
printf("x=%dn",*x);
}

laptop> ./fclc
f()
x=4
g()
x4

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).

Oui, alors que faire des gammes, tout de suite, le désir croît...

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