é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 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
Tout à fait, je l'ai vécu. Je me suis fait ma propre mnémotechnique, et tout est devenu clair. Au lieu d'écrire int *p, ou l'ambigu int * p, j'ai choisi systématiquement le int* p. p est un int*. Un pointeur vers int. C'est flagrant dans le cas du char*. A l'oral si vous ne dites pas que s est une chaîne, vous prononcerez sans doute que s est un /char étoile/. Non ? C'est cohérent avec des trucs comme: typedef char* pchar; Je sais que le typedef embarque ses pièges, mais ça rend quand même le bouzin plus lisible, quand par exemple un point est composé de N couleurs, une ligne de X points, une image de Y lignes, et une séquence de Z images.
Bien entendu le problème est que sans typedef le int* p contient un piège: int* p, q, r;
Mais je préfère ce dommage collatéral à l'écriture int *p pour déclarer p comme pointeur vers int. On va éventuellement édicter la règle de style de ne déclarer qu'un pointeur par ligne, ou de passer par un typedef.
-- Pierre Maurette
Stephane Legras-Decussy, le 14/09/2009 a écrit :
"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
Tout à fait, je l'ai vécu. Je me suis fait ma propre mnémotechnique, et
tout est devenu clair. Au lieu d'écrire int *p, ou l'ambigu int * p,
j'ai choisi systématiquement le int* p. p est un int*. Un pointeur vers
int. C'est flagrant dans le cas du char*. A l'oral si vous ne dites pas
que s est une chaîne, vous prononcerez sans doute que s est un /char
étoile/. Non ?
C'est cohérent avec des trucs comme:
typedef char* pchar;
Je sais que le typedef embarque ses pièges, mais ça rend quand même le
bouzin plus lisible, quand par exemple un point est composé de N
couleurs, une ligne de X points, une image de Y lignes, et une séquence
de Z images.
Bien entendu le problème est que sans typedef le int* p contient un
piège:
int* p, q, r;
Mais je préfère ce dommage collatéral à l'écriture int *p pour déclarer
p comme pointeur vers int. On va éventuellement édicter la règle de
style de ne déclarer qu'un pointeur par ligne, ou de passer par un
typedef.
"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
Tout à fait, je l'ai vécu. Je me suis fait ma propre mnémotechnique, et tout est devenu clair. Au lieu d'écrire int *p, ou l'ambigu int * p, j'ai choisi systématiquement le int* p. p est un int*. Un pointeur vers int. C'est flagrant dans le cas du char*. A l'oral si vous ne dites pas que s est une chaîne, vous prononcerez sans doute que s est un /char étoile/. Non ? C'est cohérent avec des trucs comme: typedef char* pchar; Je sais que le typedef embarque ses pièges, mais ça rend quand même le bouzin plus lisible, quand par exemple un point est composé de N couleurs, une ligne de X points, une image de Y lignes, et une séquence de Z images.
Bien entendu le problème est que sans typedef le int* p contient un piège: int* p, q, r;
Mais je préfère ce dommage collatéral à l'écriture int *p pour déclarer p comme pointeur vers int. On va éventuellement édicter la règle de style de ne déclarer qu'un pointeur par ligne, ou de passer par un typedef.
-- Pierre Maurette
Marc Boyer
Le 14-09-2009, Marc Espie a écrit :
In article , Gabriel Dos Reis wrote:
candide 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, | | Exact, c'est à peu près à quoi on passe son temps et c'est très ingrat car il | n'est pas du tout évident quand on part de zéro d'arriver à un code bien ciselé | comme celui d'un Plauger ou de K&R. Moi ça m'amusait mais les étudiants, en | majorité, ça les fait ch** très rapidement. Déjà, ils se disent "à quoi bon | coder un truc qui existe déjà et qui marche très bien ?"
Et je peux parfaitement comprendre leur réaction. Mon premier cours de C++ voulait m'apprendre à écrire une class IntList ; je n'y suis plus jamais retourné.
J'ai pratique l'implementation de strcpy une annee, pour voir. C'est effectivement bof.
Je leur montre un peu des trucs de style gestion de tableaux dynamiques, ce qui est plus ou moins necessaire a faire a la main en C (le style:
struct dyn { int *t; int size; int capacity; }; ) histoire qu'ils sachent a quel point c'est facile a faire, et ca permet de voir des trucs cote design d'API. Mais on fait ca ensemble en cours, et ils sont senses s'en servir ensuite.
En fait, sur une série de TD/TP, on implantait un petit bout de string.h (strlen, str[n]cpy, str[n]cat), pour bien comprendre ce qu'en C on appelle "chaine de caractères". Puis on faisait deux autres implantations du même concept, une fois sous forme de tableau dynamique genre typedef struct { char* val; size_t size; size_t capa; } string; Et une autre sous forme de liste chainée de char*.
Ca permettait d'illustrer qu'il pouvait y avoir plusieurs implantations à un concept, et ça donnait un autre habillage au "vector". La liste de tableaux de char forçait à manipuler les deux conteneur dans un même exercice.
Pour les projets, ils ont souvent le droit de se donner des tableaux de taille fixe arbitrairement grande. Tant qu'ils verifient que ca ne deborde pas, tout va bien... voire de mettre des structures de donnees triviales et peu efficaces. Ca me parait plus utile de leur expliquer COMMENT on pourra mecaniquement remplacer tout ca par des trucs plus efficaces ensuite s'ils ont bien fait leur boulot que de les faire ch* a reimplementer une n-eme bibliotheque de listes chainees/arbres equilibres, etc. Je vois des gros bouts de ca, mais en cours, pour leur montrer comment c'est cense marcher. Mais ca se dedramatise: c'est pas important. 99% de l'informatique se fait avec des structures tres simples. Si on connait un tableau redimensionnable, une table de hachage, et un arbre binaire NON equilibre, on se demerdera avec 99% des soucis. Le reste (arbre equilibre, files de priorite), ca se retrouve dans la litterature et ca s'integre UNIQUEMENT si necessaire... donc pas la peine pour 99,9% d'entre eux.
Oui, mais est-ce que "on connait" passe mieux par le fait de redévelopper ?
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, Marc Espie <espie@lain.home> a écrit :
In article <87k501n4bd.fsf@gauss.cs.tamu.edu>,
Gabriel Dos Reis <gdr@cs.tamu.edu> wrote:
candide <candide@free.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,
|
| Exact, c'est à peu près à quoi on passe son temps et c'est très ingrat car il
| n'est pas du tout évident quand on part de zéro d'arriver à un code
bien ciselé
| comme celui d'un Plauger ou de K&R. Moi ça m'amusait mais les étudiants, en
| majorité, ça les fait ch** très rapidement. Déjà, ils se disent "à quoi bon
| coder un truc qui existe déjà et qui marche très bien ?"
Et je peux parfaitement comprendre leur réaction.
Mon premier cours de C++ voulait m'apprendre à écrire une class
IntList ; je n'y suis plus jamais retourné.
J'ai pratique l'implementation de strcpy une annee, pour voir. C'est
effectivement bof.
Je leur montre un peu des trucs de style gestion de tableaux dynamiques,
ce qui est plus ou moins necessaire a faire a la main en C (le style:
struct dyn {
int *t;
int size;
int capacity;
}; )
histoire qu'ils sachent a quel point c'est facile a faire, et ca permet
de voir des trucs cote design d'API. Mais on fait ca ensemble en cours,
et ils sont senses s'en servir ensuite.
En fait, sur une série de TD/TP, on implantait un petit bout de string.h
(strlen, str[n]cpy, str[n]cat), pour bien comprendre ce qu'en C on appelle
"chaine de caractères".
Puis on faisait deux autres implantations du même concept, une fois
sous forme de tableau dynamique genre
typedef struct {
char* val;
size_t size;
size_t capa;
} string;
Et une autre sous forme de liste chainée de char*.
Ca permettait d'illustrer qu'il pouvait y avoir plusieurs implantations
à un concept, et ça donnait un autre habillage au "vector".
La liste de tableaux de char forçait à manipuler les deux conteneur
dans un même exercice.
Pour les projets, ils ont souvent le droit de se donner des tableaux de
taille fixe arbitrairement grande. Tant qu'ils verifient que ca ne deborde
pas, tout va bien... voire de mettre des structures de donnees triviales
et peu efficaces. Ca me parait plus utile de leur expliquer COMMENT on pourra
mecaniquement remplacer tout ca par des trucs plus efficaces ensuite s'ils
ont bien fait leur boulot que de les faire ch* a reimplementer une n-eme
bibliotheque de listes chainees/arbres equilibres, etc. Je vois des gros
bouts de ca, mais en cours, pour leur montrer comment c'est cense marcher.
Mais ca se dedramatise: c'est pas important. 99% de l'informatique se fait
avec des structures tres simples. Si on connait un tableau redimensionnable,
une table de hachage, et un arbre binaire NON equilibre, on se demerdera
avec 99% des soucis. Le reste (arbre equilibre, files de priorite), ca
se retrouve dans la litterature et ca s'integre UNIQUEMENT si necessaire...
donc pas la peine pour 99,9% d'entre eux.
Oui, mais est-ce que "on connait" passe mieux par le fait de redévelopper ?
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, | | Exact, c'est à peu près à quoi on passe son temps et c'est très ingrat car il | n'est pas du tout évident quand on part de zéro d'arriver à un code bien ciselé | comme celui d'un Plauger ou de K&R. Moi ça m'amusait mais les étudiants, en | majorité, ça les fait ch** très rapidement. Déjà, ils se disent "à quoi bon | coder un truc qui existe déjà et qui marche très bien ?"
Et je peux parfaitement comprendre leur réaction. Mon premier cours de C++ voulait m'apprendre à écrire une class IntList ; je n'y suis plus jamais retourné.
J'ai pratique l'implementation de strcpy une annee, pour voir. C'est effectivement bof.
Je leur montre un peu des trucs de style gestion de tableaux dynamiques, ce qui est plus ou moins necessaire a faire a la main en C (le style:
struct dyn { int *t; int size; int capacity; }; ) histoire qu'ils sachent a quel point c'est facile a faire, et ca permet de voir des trucs cote design d'API. Mais on fait ca ensemble en cours, et ils sont senses s'en servir ensuite.
En fait, sur une série de TD/TP, on implantait un petit bout de string.h (strlen, str[n]cpy, str[n]cat), pour bien comprendre ce qu'en C on appelle "chaine de caractères". Puis on faisait deux autres implantations du même concept, une fois sous forme de tableau dynamique genre typedef struct { char* val; size_t size; size_t capa; } string; Et une autre sous forme de liste chainée de char*.
Ca permettait d'illustrer qu'il pouvait y avoir plusieurs implantations à un concept, et ça donnait un autre habillage au "vector". La liste de tableaux de char forçait à manipuler les deux conteneur dans un même exercice.
Pour les projets, ils ont souvent le droit de se donner des tableaux de taille fixe arbitrairement grande. Tant qu'ils verifient que ca ne deborde pas, tout va bien... voire de mettre des structures de donnees triviales et peu efficaces. Ca me parait plus utile de leur expliquer COMMENT on pourra mecaniquement remplacer tout ca par des trucs plus efficaces ensuite s'ils ont bien fait leur boulot que de les faire ch* a reimplementer une n-eme bibliotheque de listes chainees/arbres equilibres, etc. Je vois des gros bouts de ca, mais en cours, pour leur montrer comment c'est cense marcher. Mais ca se dedramatise: c'est pas important. 99% de l'informatique se fait avec des structures tres simples. Si on connait un tableau redimensionnable, une table de hachage, et un arbre binaire NON equilibre, on se demerdera avec 99% des soucis. Le reste (arbre equilibre, files de priorite), ca se retrouve dans la litterature et ca s'integre UNIQUEMENT si necessaire... donc pas la peine pour 99,9% d'entre eux.
Oui, mais est-ce que "on connait" passe mieux par le fait de redévelopper ?
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
Le 14-09-2009, Gabriel Dos Reis a écrit :
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.
Disons qu'on commence par des petits programmes, puis on ajoute des fonctions, puis on écrit des modules sans programme (avec juste un prog de tests unitaires), et tout cela nous ammène au projet...
| 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.
Heuh... Disons que dès que ça dépasse les 1000 lignes de code, dans un seul fichier, ça devient pénible.
Le pauvre gars devrait peut être apprendre à écrire de simples programmes d'abord avant de s'occuper de l'organisation. Je pense.
Oui, le premier 1/3 - 1/4 du déroulement de l'enseignement.
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.
Oulà... Non, mes étudiants n'ont jamais eut ce travers.
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 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.
Disons qu'on commence par des petits programmes, puis on
ajoute des fonctions, puis on écrit des modules sans programme
(avec juste un prog de tests unitaires), et tout cela nous
ammène au projet...
| 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.
Heuh... Disons que dès que ça dépasse les 1000 lignes de code,
dans un seul fichier, ça devient pénible.
Le pauvre gars devrait peut être apprendre à écrire de simples
programmes d'abord avant de s'occuper de l'organisation. Je pense.
Oui, le premier 1/3 - 1/4 du déroulement de l'enseignement.
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.
Oulà... Non, mes étudiants n'ont jamais eut ce travers.
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 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.
Disons qu'on commence par des petits programmes, puis on ajoute des fonctions, puis on écrit des modules sans programme (avec juste un prog de tests unitaires), et tout cela nous ammène au projet...
| 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.
Heuh... Disons que dès que ça dépasse les 1000 lignes de code, dans un seul fichier, ça devient pénible.
Le pauvre gars devrait peut être apprendre à écrire de simples programmes d'abord avant de s'occuper de l'organisation. Je pense.
Oui, le premier 1/3 - 1/4 du déroulement de l'enseignement.
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.
Oulà... Non, mes étudiants n'ont jamais eut ce travers.
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
Le 14-09-2009, Jean-Marc Bourguet a écrit :
Marc Boyer writes:
POur dire les choses, j'ai été très sceptique sur l'utilité de la connaissance de C pour apprendre C++ jusqu'à lire « Accelerated C++ ».
J'ai l'impression que tu veux dire l'inverse de ce que tu as écrit.
Oui, tout à fait. "C'est pour voir si vous suivez" (excuse bidon d'enseignant)
Marc Boyer PS: Il y a donc des gens qui lisent cette discussion... -- 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, Jean-Marc Bourguet <jm@bourguet.org> a écrit :
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> writes:
POur dire les choses, j'ai été très sceptique sur l'utilité
de la connaissance de C pour apprendre C++ jusqu'à lire
« Accelerated C++ ».
J'ai l'impression que tu veux dire l'inverse de ce que tu as écrit.
Oui, tout à fait.
"C'est pour voir si vous suivez" (excuse bidon d'enseignant)
Marc Boyer
PS: Il y a donc des gens qui lisent cette discussion...
--
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
POur dire les choses, j'ai été très sceptique sur l'utilité de la connaissance de C pour apprendre C++ jusqu'à lire « Accelerated C++ ».
J'ai l'impression que tu veux dire l'inverse de ce que tu as écrit.
Oui, tout à fait. "C'est pour voir si vous suivez" (excuse bidon d'enseignant)
Marc Boyer PS: Il y a donc des gens qui lisent cette discussion... -- 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
Le 14-09-2009, Stephane Legras-Decussy a écrit :
"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...
Oui, et ils ont du mal d'ailleurs. "Mais pourquoi il faut sauvegarder avant de compiler" voir le célèbre "Monsieur, tout à l'heure, j'ai fait exactement ce que vous avez fait, et ça compilait pas" et puis "Je crois que j'ai trouvé un bug [de gcc]"
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, Stephane Legras-Decussy <killyourself@yesnocancel.com> a écrit :
"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...
Oui, et ils ont du mal d'ailleurs.
"Mais pourquoi il faut sauvegarder avant de compiler"
voir le célèbre
"Monsieur, tout à l'heure, j'ai fait exactement ce que vous
avez fait, et ça compilait pas"
et puis
"Je crois que j'ai trouvé un bug [de gcc]"
Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0
"Marc Boyer" a écrit 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...
Oui, et ils ont du mal d'ailleurs. "Mais pourquoi il faut sauvegarder avant de compiler" voir le célèbre "Monsieur, tout à l'heure, j'ai fait exactement ce que vous avez fait, et ça compilait pas" et puis "Je crois que j'ai trouvé un bug [de gcc]"
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
ld
On 14 sep, 14:56, (Marc Espie) wrote:
a 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.
Perso, je n'ai aucune aversion pour C++. Comme je l'ai deja dit, je serais fortement interesse si C++ (ou un autre langage, mais C++ en particulier) me permettait de faire ce que fait COS, ca m'eviterait de le maintenir. Ceci dit, ca doit faire un an que je n'ai pas touche aux macros de COS. La partie orientee-objet n'est que la partie emergee de l'iceberg (comme en C++). Mais pour s'en appercevoir, il faut d'abord comprendre ce qu'est COS...
A titre d'exemple, et en procedant de maniere incrementale (configurable au runtime, biensur), j'aimerais voir comment en C++ on ecrit:
1) une classe generique qui evite les deadlocks sur des objets partages par plusieurs threads. ex: shared_object = gnewWith(Locker, object); // declare en global OBJ object_concat = gcat(shared_object, shared_object); // pas de deadlock.
2) une classe generique qui permet de creer des fermetures (closures) ex: OBJ incr = aFunctor(gaddTo, 0, aInt(1)); geval(incr, object); // increment object: gaddTo(object, aInt (1))
3) une classe generique qui permet de serialiser les proprietes des objets ex: gput(stream, object);
4) une classe generique qui permet de distribuer des taches (fermetures) sur un pool de threads (avec re-repartition par vol de tache) ex: gput(pool, aFunctor(the_task));
5) une classe generique qui permet de distribuer des taches sur des serveurs lorque les threads locaux sont trop charges. ex: gput(pool, aFunctor(the_task)); // cette fois, the_task doit etre une methode pour etre serialisable
Pour l'instant les points 4) et 5) ne sont pas realises en COS faute de temps et de moyen mais autant que je sache, il n'y aucune difficulte technique a le faire en COS, juste du code a ecrire et des choix (protocole, compatibilite) a faire.
a+, ld.
On 14 sep, 14:56, es...@lain.home (Marc Espie) wrote:
a 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.
Perso, je n'ai aucune aversion pour C++. Comme je l'ai deja dit, je
serais fortement interesse si C++ (ou un autre langage, mais C++ en
particulier) me permettait de faire ce que fait COS, ca m'eviterait de
le maintenir. Ceci dit, ca doit faire un an que je n'ai pas touche aux
macros de COS. La partie orientee-objet n'est que la partie emergee de
l'iceberg (comme en C++). Mais pour s'en appercevoir, il faut d'abord
comprendre ce qu'est COS...
A titre d'exemple, et en procedant de maniere incrementale
(configurable au runtime, biensur), j'aimerais voir comment en C++ on
ecrit:
1) une classe generique qui evite les deadlocks sur des objets
partages par plusieurs threads.
ex: shared_object = gnewWith(Locker, object); // declare en global
OBJ object_concat = gcat(shared_object, shared_object); // pas
de deadlock.
2) une classe generique qui permet de creer des fermetures (closures)
ex: OBJ incr = aFunctor(gaddTo, 0, aInt(1));
geval(incr, object); // increment object: gaddTo(object, aInt
(1))
3) une classe generique qui permet de serialiser les proprietes des
objets
ex: gput(stream, object);
4) une classe generique qui permet de distribuer des taches
(fermetures) sur un pool de threads (avec re-repartition par vol de
tache)
ex: gput(pool, aFunctor(the_task));
5) une classe generique qui permet de distribuer des taches sur des
serveurs lorque les threads locaux sont trop charges.
ex: gput(pool, aFunctor(the_task)); // cette fois, the_task doit
etre une methode pour etre serialisable
Pour l'instant les points 4) et 5) ne sont pas realises en COS faute
de temps et de moyen mais autant que je sache, il n'y aucune
difficulte technique a le faire en COS, juste du code a ecrire et des
choix (protocole, compatibilite) a faire.
a 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.
Perso, je n'ai aucune aversion pour C++. Comme je l'ai deja dit, je serais fortement interesse si C++ (ou un autre langage, mais C++ en particulier) me permettait de faire ce que fait COS, ca m'eviterait de le maintenir. Ceci dit, ca doit faire un an que je n'ai pas touche aux macros de COS. La partie orientee-objet n'est que la partie emergee de l'iceberg (comme en C++). Mais pour s'en appercevoir, il faut d'abord comprendre ce qu'est COS...
A titre d'exemple, et en procedant de maniere incrementale (configurable au runtime, biensur), j'aimerais voir comment en C++ on ecrit:
1) une classe generique qui evite les deadlocks sur des objets partages par plusieurs threads. ex: shared_object = gnewWith(Locker, object); // declare en global OBJ object_concat = gcat(shared_object, shared_object); // pas de deadlock.
2) une classe generique qui permet de creer des fermetures (closures) ex: OBJ incr = aFunctor(gaddTo, 0, aInt(1)); geval(incr, object); // increment object: gaddTo(object, aInt (1))
3) une classe generique qui permet de serialiser les proprietes des objets ex: gput(stream, object);
4) une classe generique qui permet de distribuer des taches (fermetures) sur un pool de threads (avec re-repartition par vol de tache) ex: gput(pool, aFunctor(the_task));
5) une classe generique qui permet de distribuer des taches sur des serveurs lorque les threads locaux sont trop charges. ex: gput(pool, aFunctor(the_task)); // cette fois, the_task doit etre une methode pour etre serialisable
Pour l'instant les points 4) et 5) ne sont pas realises en COS faute de temps et de moyen mais autant que je sache, il n'y aucune difficulte technique a le faire en COS, juste du code a ecrire et des choix (protocole, compatibilite) a faire.
C'est possible. Mais une chose est certaine, c'est qu'il est très difficile de se mettre dans la situation de quelqu'un qui ignore des choses que nous savons. Pour être plus clair, je dirais que tous les gens que je lis et qui affirment que la connaissance du C n'est pas utile à l'apprentissage du C++ - ce n'est qu'un exemple - sont de niveau expert en C. Gabriel Dos Reis est un bon exemple.
Mon affirmation est tirée de la practique de l'enseignement de la programmation en C, C++, Java, Haskell, etc. à des niveaux variés et à des publics variés sur plus d'une décennie.
CQFD. Merci.
-- Pierre Maurette
Gabriel Dos Reis, le 14/09/2009 a écrit :
Pierre Maurette <maurettepierre@wanadoo.fr> writes:
[...]
C'est possible. Mais une chose est certaine, c'est qu'il est très
difficile de se mettre dans la situation de quelqu'un qui ignore des
choses que nous savons. Pour être plus clair, je dirais que tous les
gens que je lis et qui affirment que la connaissance du C n'est pas
utile à l'apprentissage du C++ - ce n'est qu'un exemple - sont de
niveau expert en C. Gabriel Dos Reis est un bon exemple.
Mon affirmation est tirée de la practique de l'enseignement de la
programmation en C, C++, Java, Haskell, etc. à des niveaux variés et à
des publics variés sur plus d'une décennie.
C'est possible. Mais une chose est certaine, c'est qu'il est très difficile de se mettre dans la situation de quelqu'un qui ignore des choses que nous savons. Pour être plus clair, je dirais que tous les gens que je lis et qui affirment que la connaissance du C n'est pas utile à l'apprentissage du C++ - ce n'est qu'un exemple - sont de niveau expert en C. Gabriel Dos Reis est un bon exemple.
Mon affirmation est tirée de la practique de l'enseignement de la programmation en C, C++, Java, Haskell, etc. à des niveaux variés et à des publics variés sur plus d'une décennie.
