turpitudes du c : prototype de fonction erreur de code ou erreur avec l'ide geany sur ubuntu
16 réponses
bpascal123
Bonjour cyberespace,
je viens de me rendre compte que quand je d=E9clare le prototype de la
fonction suivante :
15: void CheckFile(FILE *FP_FILE) ;
le message de precompilation :
gcc -Wall -o "exPract1" "exPract1.c" (in directory: /media/XP/code_c)
exPract1.c: In function =91main=92:
exPract1.c:15: note: expected =91struct FILE *=92 but argument is of type
=91char *=92
Compilation finished successfully.
Je r=E9p=E8te des exercices beaucoup de fois avec des noms de variables ou
fonctions diff=E9rents alors peut-=EAtre (tr=E8s probablement) j'ai d=E9j=
=E0
utilis=E9 le nom CheckFile comme nom de fonction. Mais aucun souvenir
d'y avoir d=E9clar=E9 une structure comme param=E8tre... Mon ide est geany.
Peut-=EAtre CheckFile est dans le cache de l'ide???
Ce qui me fait supposer que =E7a vient de l'ide est que si je change de
nom, par exemple : CheckMyFile, =E7a fonctionne sans messages...
gcc -Wall -o "exPract1" "exPract1.c" (in directory: /media/XP/code_c) exPract1.c: In function ÂmainÂ:
exPract1.c:15: note: expected Âstruct FILE *Â but argument is o f type Âchar *Â
FILE est une macro, apparent definie a struct FILE dans ton cas.
Le probleme est que tu as un appel a CheckFile a la ligne 15 de exPract1.c (si la ligne que tu as donnee ci-dessus est celle de exPract1.c, donne tout le fichier si il est de taille raisonnable) qui a comme argument un char* plutot qu'un FILE*.
A+
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
gcc -Wall -o "exPract1" "exPract1.c" (in directory: /media/XP/code_c)
exPract1.c: In function ÂmainÂ:
exPract1.c:15: note: expected Âstruct FILE *Â but argument is o f type
Âchar *Â
FILE est une macro, apparent definie a struct FILE dans ton cas.
Le probleme est que tu as un appel a CheckFile a la ligne 15 de exPract1.c
(si la ligne que tu as donnee ci-dessus est celle de exPract1.c, donne tout
le fichier si il est de taille raisonnable) qui a comme argument un char*
plutot qu'un FILE*.
A+
--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org
gcc -Wall -o "exPract1" "exPract1.c" (in directory: /media/XP/code_c) exPract1.c: In function ÂmainÂ:
exPract1.c:15: note: expected Âstruct FILE *Â but argument is o f type Âchar *Â
FILE est une macro, apparent definie a struct FILE dans ton cas.
Le probleme est que tu as un appel a CheckFile a la ligne 15 de exPract1.c (si la ligne que tu as donnee ci-dessus est celle de exPract1.c, donne tout le fichier si il est de taille raisonnable) qui a comme argument un char* plutot qu'un FILE*.
A+
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
bpascal123
Voici le programme qui entraîne un message sur la ligne "void OpenFileM(FILE *FP_FILE) ;" avec quelque chose comme FP_FILE devraît être une structure
Je viens de me rendre compte que même si je change le nom de la fonction OpenFileM, le message qui apparaît lors de la compilation continue à apparaître.
Mais le programme s'exécute comme attendue. Je ne sais pas à quoi est dû ce message.
Voici le programme qui entraîne un message sur la ligne "void
OpenFileM(FILE *FP_FILE) ;" avec quelque chose comme FP_FILE devraît
être une structure
Je viens de me rendre compte que même si je change le nom de la
fonction OpenFileM, le message qui apparaît lors de la compilation
continue à apparaître.
Mais le programme s'exécute comme attendue. Je ne sais pas à quoi est
dû ce message.
Voici le programme qui entraîne un message sur la ligne "void OpenFileM(FILE *FP_FILE) ;" avec quelque chose comme FP_FILE devraît être une structure
Je viens de me rendre compte que même si je change le nom de la fonction OpenFileM, le message qui apparaît lors de la compilation continue à apparaître.
Mais le programme s'exécute comme attendue. Je ne sais pas à quoi est dû ce message.
Après une seconde lecture de votre post Jean-Marc, je viens de voir l'erreur. J'appel CheckFile avec un argument de type char au lieu de *FILE ... Confusion de noms...
ça devrait etre: ... printf("nOuverture de "data15a.txt" : n") ; MP_SOURCE = fopen(MPSource, "r") ; OpenFileM(MP_SOURCE) ; ... Ce qui m'a troublé, c'est le message du compilateur qui fait mention d'une structure quelque part...
Mais par ce message d'erreur résolu, je pense comprendre que FILE * est une structure ou plutot un pointeur vers une structure (j'ai une expérience trop négligeable des structures pour essayer de comprendre plus loin).
Si j'essaye d'écrire dans le prototype de la fonction : CheckFile(struct FILE *FP_FILE) ; ?
ça ne donne pas le résultat prévu:
gcc -Wall -c "exPract1.c" (in directory: /media/XP/code_c/encours) exPract1.c:15: warning: struct FILE declared inside parameter list exPract1.c:15: warning: its scope is only this definition or declaration, which is probably not what you want exPract1.c: In function main: exPract1.c:31: warning: passing argument 1 of OpenFile from incompatible pointer type exPract1.c:15: note: expected struct FILE * but argument is of type struct FILE * exPract1.c: At top level: exPract1.c:54: warning: struct FILE declared inside parameter list exPract1.c:54: error: conflicting types for OpenFile exPract1.c:15: note: previous declaration of OpenFile was here Compilation failed.
C'est juste une expérimentation parmi tant d'autre que le langage c permet de faire. En fait ce n'est pas un langage qui permet tant d'expérimentation pour être honnête, à mon niveau de débutant, to ut semble avoir été prévu. Je compte explorer encore un peu ce langage pour être plus à l'aise avec des types de données qu'on retrouve dans d'autres langages, notamment les langages objets.
Merci
Après une seconde lecture de votre post Jean-Marc, je viens de voir
l'erreur.
J'appel CheckFile avec un argument de type char au lieu de *FILE ...
Confusion de noms...
ça devrait etre:
...
printf("nOuverture de "data15a.txt" : n") ;
MP_SOURCE = fopen(MPSource, "r") ;
OpenFileM(MP_SOURCE) ;
...
Ce qui m'a troublé, c'est le message du compilateur qui fait mention
d'une structure quelque part...
Mais par ce message d'erreur résolu, je pense comprendre que FILE *
est une structure ou plutot un pointeur vers une structure (j'ai une
expérience trop négligeable des structures pour essayer de comprendre
plus loin).
Si j'essaye d'écrire dans le prototype de la fonction :
CheckFile(struct FILE *FP_FILE) ; ?
ça ne donne pas le résultat prévu:
gcc -Wall -c "exPract1.c" (in directory: /media/XP/code_c/encours)
exPract1.c:15: warning: struct FILE declared inside parameter list
exPract1.c:15: warning: its scope is only this definition or
declaration, which is probably not what you want
exPract1.c: In function main:
exPract1.c:31: warning: passing argument 1 of OpenFile from
incompatible pointer type
exPract1.c:15: note: expected struct FILE * but argument is of type
struct FILE *
exPract1.c: At top level:
exPract1.c:54: warning: struct FILE declared inside parameter list
exPract1.c:54: error: conflicting types for OpenFile
exPract1.c:15: note: previous declaration of OpenFile was here
Compilation failed.
C'est juste une expérimentation parmi tant d'autre que le langage c
permet de faire. En fait ce n'est pas un langage qui permet tant
d'expérimentation pour être honnête, à mon niveau de débutant, to ut
semble avoir été prévu. Je compte explorer encore un peu ce langage
pour être plus à l'aise avec des types de données qu'on retrouve dans
d'autres langages, notamment les langages objets.
Après une seconde lecture de votre post Jean-Marc, je viens de voir l'erreur. J'appel CheckFile avec un argument de type char au lieu de *FILE ... Confusion de noms...
ça devrait etre: ... printf("nOuverture de "data15a.txt" : n") ; MP_SOURCE = fopen(MPSource, "r") ; OpenFileM(MP_SOURCE) ; ... Ce qui m'a troublé, c'est le message du compilateur qui fait mention d'une structure quelque part...
Mais par ce message d'erreur résolu, je pense comprendre que FILE * est une structure ou plutot un pointeur vers une structure (j'ai une expérience trop négligeable des structures pour essayer de comprendre plus loin).
Si j'essaye d'écrire dans le prototype de la fonction : CheckFile(struct FILE *FP_FILE) ; ?
ça ne donne pas le résultat prévu:
gcc -Wall -c "exPract1.c" (in directory: /media/XP/code_c/encours) exPract1.c:15: warning: struct FILE declared inside parameter list exPract1.c:15: warning: its scope is only this definition or declaration, which is probably not what you want exPract1.c: In function main: exPract1.c:31: warning: passing argument 1 of OpenFile from incompatible pointer type exPract1.c:15: note: expected struct FILE * but argument is of type struct FILE * exPract1.c: At top level: exPract1.c:54: warning: struct FILE declared inside parameter list exPract1.c:54: error: conflicting types for OpenFile exPract1.c:15: note: previous declaration of OpenFile was here Compilation failed.
C'est juste une expérimentation parmi tant d'autre que le langage c permet de faire. En fait ce n'est pas un langage qui permet tant d'expérimentation pour être honnête, à mon niveau de débutant, to ut semble avoir été prévu. Je compte explorer encore un peu ce langage pour être plus à l'aise avec des types de données qu'on retrouve dans d'autres langages, notamment les langages objets.
Merci
Jean-Marc Bourguet
"" writes:
En fait ce n'est pas un langage qui permet tant d'expérimentation pour être honnête
Le C n'est pas un langage qui peut etre appris par experimentation. Il y a un beaucoup trop de choses non definies, non specifiees et definies par l'implementation pour ca. On peut arriver par experimentation a avoir le resultat, mais les raisons qui font que l'on obtienne ce resultat tiennent du hasard, donc les circonstances changeant un peu, on ne l'obtient plus.
A+
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
En fait ce n'est pas un langage qui permet tant
d'expérimentation pour être honnête
Le C n'est pas un langage qui peut etre appris par experimentation. Il y a
un beaucoup trop de choses non definies, non specifiees et definies par
l'implementation pour ca. On peut arriver par experimentation a avoir le
resultat, mais les raisons qui font que l'on obtienne ce resultat tiennent
du hasard, donc les circonstances changeant un peu, on ne l'obtient plus.
A+
--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org
En fait ce n'est pas un langage qui permet tant d'expérimentation pour être honnête
Le C n'est pas un langage qui peut etre appris par experimentation. Il y a un beaucoup trop de choses non definies, non specifiees et definies par l'implementation pour ca. On peut arriver par experimentation a avoir le resultat, mais les raisons qui font que l'on obtienne ce resultat tiennent du hasard, donc les circonstances changeant un peu, on ne l'obtient plus.
A+
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
candide
Jean-Marc Bourguet a écrit :
"" writes:
En fait ce n'est pas un langage qui permet tant d'expérimentation pour être honnête
Le C n'est pas un langage qui peut etre appris par experimentation. Il y a un beaucoup trop de choses non definies, non specifiees et definies par l'implementation pour ca.
Le débutant cherche déjà à comprendre comment ça fonctionne dans son implémentation (et encore, il ne le dira pas comme ça, parce que le débutant ne sait pas vraiment ce que recouvre ce terme d'"implémentation").
Les expérimentations sont un moyen d'apprendre et surtout de comprendre comment le code qu'écrit le débutant s'exécute sur la machine. Cela correspond souvent à une stratégie d'essais/erreurs. Je crois qu'il faut féliciter le PO de prendre ce genre d'initiative, beaucoup de débutants n'osent pas les engager. Au passage, je ferais remarquer que de nombreux intervenants très pragmatiques de ce forum prônent implicitement un apprentissage occasionnel par expérimentations. Hélas, que les débutants (et moins débutants aussi d'ailleurs) doivent recourir à ce type d'apprentissages montre surtout à quel point la documentation sur le langage C est défaillante ...
En fait ce n'est pas un langage qui permet tant
d'expérimentation pour être honnête
Le C n'est pas un langage qui peut etre appris par experimentation. Il y a
un beaucoup trop de choses non definies, non specifiees et definies par
l'implementation pour ca.
Le débutant cherche déjà à comprendre comment ça fonctionne dans son
implémentation (et encore, il ne le dira pas comme ça, parce que le
débutant ne sait pas vraiment ce que recouvre ce terme d'"implémentation").
Les expérimentations sont un moyen d'apprendre et surtout de comprendre
comment le code qu'écrit le débutant s'exécute sur la machine. Cela
correspond souvent à une stratégie d'essais/erreurs. Je crois qu'il faut
féliciter le PO de prendre ce genre d'initiative, beaucoup de
débutants n'osent pas les engager. Au passage, je ferais remarquer que
de nombreux intervenants très pragmatiques de ce forum prônent
implicitement un apprentissage occasionnel par expérimentations. Hélas,
que les débutants (et moins débutants aussi d'ailleurs) doivent recourir
à ce type d'apprentissages montre surtout à quel point la documentation
sur le langage C est défaillante ...
En fait ce n'est pas un langage qui permet tant d'expérimentation pour être honnête
Le C n'est pas un langage qui peut etre appris par experimentation. Il y a un beaucoup trop de choses non definies, non specifiees et definies par l'implementation pour ca.
Le débutant cherche déjà à comprendre comment ça fonctionne dans son implémentation (et encore, il ne le dira pas comme ça, parce que le débutant ne sait pas vraiment ce que recouvre ce terme d'"implémentation").
Les expérimentations sont un moyen d'apprendre et surtout de comprendre comment le code qu'écrit le débutant s'exécute sur la machine. Cela correspond souvent à une stratégie d'essais/erreurs. Je crois qu'il faut féliciter le PO de prendre ce genre d'initiative, beaucoup de débutants n'osent pas les engager. Au passage, je ferais remarquer que de nombreux intervenants très pragmatiques de ce forum prônent implicitement un apprentissage occasionnel par expérimentations. Hélas, que les débutants (et moins débutants aussi d'ailleurs) doivent recourir à ce type d'apprentissages montre surtout à quel point la documentation sur le langage C est défaillante ...
espie
In article <4ca79cc3$0$29685$, candide wrote:
implicitement un apprentissage occasionnel par expérimentations. Hélas, que les débutants (et moins débutants aussi d'ailleurs) doivent recourir à ce type d'apprentissages montre surtout à quel point la documentation sur le langage C est défaillante ...
Non, faut arreter les conneries, la.
La documentation n'est pas defaillante, mais il y a des points tres precis relativement obscurs, comme dans tout langage relativement complet.
On peut tres bien faire du C et rester dans les 99,9% qui sont balises, qui sont clairs et comprehensibles. C'est d'ailleurs ce que font les non-debutants l'essentiel du temps, simplement, ils n'eprouvent pas le besoin de venir le raconter ici "ouaich, je fais du C, je comprends parfaitement ce que je fais, et ca marche"...
Tu as une notion d'_undefined behavior_ dans la norme: c'est parfaitement clair: tu es sorti du langage a proprement parler, ca peut faire n'importe quoi. C'est comme traverser en dehors des clous. C'est dangereux.
Disserter sur ce que ca va faire, c'est possible. Et ca peut demander d'experimenter. Mais ca ne veut pas dire que la documentation est defaillante. La documentation se contente de dire ce qui se passe quand on fait ce qui est prevue, et se dedouane explicitement lorsqu'on fait quelque chose qui n'est pas prevu.
Tu peux dire bien des choses sur le C, sur le fait que c'est dur a apprendre, dur a faire marcher. Mais mal documente ? bof, bof, bof.
In article <4ca79cc3$0$29685$426a34cc@news.free.fr>,
candide <candide@free.invalid> wrote:
implicitement un apprentissage occasionnel par expérimentations. Hélas,
que les débutants (et moins débutants aussi d'ailleurs) doivent recourir
à ce type d'apprentissages montre surtout à quel point la documentation
sur le langage C est défaillante ...
Non, faut arreter les conneries, la.
La documentation n'est pas defaillante, mais il y a des points tres precis
relativement obscurs, comme dans tout langage relativement complet.
On peut tres bien faire du C et rester dans les 99,9% qui sont balises,
qui sont clairs et comprehensibles. C'est d'ailleurs ce que font les
non-debutants l'essentiel du temps, simplement, ils n'eprouvent pas le
besoin de venir le raconter ici "ouaich, je fais du C, je comprends
parfaitement ce que je fais, et ca marche"...
Tu as une notion d'_undefined behavior_ dans la norme: c'est parfaitement
clair: tu es sorti du langage a proprement parler, ca peut faire n'importe
quoi. C'est comme traverser en dehors des clous. C'est dangereux.
Disserter sur ce que ca va faire, c'est possible. Et ca peut demander
d'experimenter. Mais ca ne veut pas dire que la documentation est
defaillante. La documentation se contente de dire ce qui se passe quand
on fait ce qui est prevue, et se dedouane explicitement lorsqu'on fait
quelque chose qui n'est pas prevu.
Tu peux dire bien des choses sur le C, sur le fait que c'est dur a apprendre,
dur a faire marcher. Mais mal documente ? bof, bof, bof.
implicitement un apprentissage occasionnel par expérimentations. Hélas, que les débutants (et moins débutants aussi d'ailleurs) doivent recourir à ce type d'apprentissages montre surtout à quel point la documentation sur le langage C est défaillante ...
Non, faut arreter les conneries, la.
La documentation n'est pas defaillante, mais il y a des points tres precis relativement obscurs, comme dans tout langage relativement complet.
On peut tres bien faire du C et rester dans les 99,9% qui sont balises, qui sont clairs et comprehensibles. C'est d'ailleurs ce que font les non-debutants l'essentiel du temps, simplement, ils n'eprouvent pas le besoin de venir le raconter ici "ouaich, je fais du C, je comprends parfaitement ce que je fais, et ca marche"...
Tu as une notion d'_undefined behavior_ dans la norme: c'est parfaitement clair: tu es sorti du langage a proprement parler, ca peut faire n'importe quoi. C'est comme traverser en dehors des clous. C'est dangereux.
Disserter sur ce que ca va faire, c'est possible. Et ca peut demander d'experimenter. Mais ca ne veut pas dire que la documentation est defaillante. La documentation se contente de dire ce qui se passe quand on fait ce qui est prevue, et se dedouane explicitement lorsqu'on fait quelque chose qui n'est pas prevu.
Tu peux dire bien des choses sur le C, sur le fait que c'est dur a apprendre, dur a faire marcher. Mais mal documente ? bof, bof, bof.
Wykaaa
Marc Espie a écrit :
In article <4ca79cc3$0$29685$, candide wrote:
implicitement un apprentissage occasionnel par expérimentations. Hélas, que les débutants (et moins débutants aussi d'ailleurs) doivent recourir à ce type d'apprentissages montre surtout à quel point la documentation sur le langage C est défaillante ...
Non, faut arreter les conneries, la.
La documentation n'est pas defaillante, mais il y a des points tres precis relativement obscurs, comme dans tout langage relativement complet.
On peut tres bien faire du C et rester dans les 99,9% qui sont balises, qui sont clairs et comprehensibles. C'est d'ailleurs ce que font les non-debutants l'essentiel du temps, simplement, ils n'eprouvent pas le besoin de venir le raconter ici "ouaich, je fais du C, je comprends parfaitement ce que je fais, et ca marche"...
Tu as une notion d'_undefined behavior_ dans la norme: c'est parfaitement clair: tu es sorti du langage a proprement parler, ca peut faire n'importe quoi. C'est comme traverser en dehors des clous. C'est dangereux.
Disserter sur ce que ca va faire, c'est possible. Et ca peut demander d'experimenter. Mais ca ne veut pas dire que la documentation est defaillante. La documentation se contente de dire ce qui se passe quand on fait ce qui est prevue, et se dedouane explicitement lorsqu'on fait quelque chose qui n'est pas prevu.
Tu peux dire bien des choses sur le C, sur le fait que c'est dur a apprendre, dur a faire marcher. Mais mal documente ? bof, bof, bof.
Bravo Marc. C'est exactement ça et maintenant, s'il y en a qui veulent mettre leur égo dans la programmation, c'est leur problème mais la première chose que j'ai écrite dans tous les cours d'initiation à la programmation que j'ai faits c'est : egoless programming !
Et puis les professionnels savent bien qu'il faut respecter le principe du KISS (Keep It Short and Simple).
Vouloir "jouer" avec les traits les plus obscurs d'un langage de programmation (que ce soit C ou un autre) ne peut que se retourner contre le "joueur".
Ceci étant, je ne suis pas partisan de la méthode essai/erreur, tant pour l'apprentissage que pour le "job" mais pour un apprentissage "raisonné" de la programmation et d'un langage.
D'autre part, j'ai toujours considéré, et je le pense encore, même maintenant que je suis à la retraite, qu'apprendre à programmer en commençant par le langage C est une hérésie.
Par ailleurs, et pour finir (pour cette fois...), il me semble que la doc sur le langage C est tout à fait dans la moyenne et même, un peu au-dessus. Ce n'était évidemment pas le cas à l'époque du C dit de K&R (avant la norme ANSII) où la seule doc existante était la première édition du K&R. Heureusement qu'il y a eu, assez rapidement, le Harbison et Steele !
Marc Espie a écrit :
In article <4ca79cc3$0$29685$426a34cc@news.free.fr>,
candide <candide@free.invalid> wrote:
implicitement un apprentissage occasionnel par expérimentations. Hélas,
que les débutants (et moins débutants aussi d'ailleurs) doivent recourir
à ce type d'apprentissages montre surtout à quel point la documentation
sur le langage C est défaillante ...
Non, faut arreter les conneries, la.
La documentation n'est pas defaillante, mais il y a des points tres precis
relativement obscurs, comme dans tout langage relativement complet.
On peut tres bien faire du C et rester dans les 99,9% qui sont balises,
qui sont clairs et comprehensibles. C'est d'ailleurs ce que font les
non-debutants l'essentiel du temps, simplement, ils n'eprouvent pas le
besoin de venir le raconter ici "ouaich, je fais du C, je comprends
parfaitement ce que je fais, et ca marche"...
Tu as une notion d'_undefined behavior_ dans la norme: c'est parfaitement
clair: tu es sorti du langage a proprement parler, ca peut faire n'importe
quoi. C'est comme traverser en dehors des clous. C'est dangereux.
Disserter sur ce que ca va faire, c'est possible. Et ca peut demander
d'experimenter. Mais ca ne veut pas dire que la documentation est
defaillante. La documentation se contente de dire ce qui se passe quand
on fait ce qui est prevue, et se dedouane explicitement lorsqu'on fait
quelque chose qui n'est pas prevu.
Tu peux dire bien des choses sur le C, sur le fait que c'est dur a apprendre,
dur a faire marcher. Mais mal documente ? bof, bof, bof.
Bravo Marc. C'est exactement ça et maintenant, s'il y en a qui veulent
mettre leur égo dans la programmation, c'est leur problème mais la
première chose que j'ai écrite dans tous les cours d'initiation à la
programmation que j'ai faits c'est : egoless programming !
Et puis les professionnels savent bien qu'il faut respecter le principe
du KISS (Keep It Short and Simple).
Vouloir "jouer" avec les traits les plus obscurs d'un langage de
programmation (que ce soit C ou un autre) ne peut que se retourner
contre le "joueur".
Ceci étant, je ne suis pas partisan de la méthode essai/erreur, tant
pour l'apprentissage que pour le "job" mais pour un apprentissage
"raisonné" de la programmation et d'un langage.
D'autre part, j'ai toujours considéré, et je le pense encore, même
maintenant que je suis à la retraite, qu'apprendre à programmer en
commençant par le langage C est une hérésie.
Par ailleurs, et pour finir (pour cette fois...), il me semble que la
doc sur le langage C est tout à fait dans la moyenne et même, un peu
au-dessus. Ce n'était évidemment pas le cas à l'époque du C dit de K&R
(avant la norme ANSII) où la seule doc existante était la première
édition du K&R. Heureusement qu'il y a eu, assez rapidement, le Harbison
et Steele !
implicitement un apprentissage occasionnel par expérimentations. Hélas, que les débutants (et moins débutants aussi d'ailleurs) doivent recourir à ce type d'apprentissages montre surtout à quel point la documentation sur le langage C est défaillante ...
Non, faut arreter les conneries, la.
La documentation n'est pas defaillante, mais il y a des points tres precis relativement obscurs, comme dans tout langage relativement complet.
On peut tres bien faire du C et rester dans les 99,9% qui sont balises, qui sont clairs et comprehensibles. C'est d'ailleurs ce que font les non-debutants l'essentiel du temps, simplement, ils n'eprouvent pas le besoin de venir le raconter ici "ouaich, je fais du C, je comprends parfaitement ce que je fais, et ca marche"...
Tu as une notion d'_undefined behavior_ dans la norme: c'est parfaitement clair: tu es sorti du langage a proprement parler, ca peut faire n'importe quoi. C'est comme traverser en dehors des clous. C'est dangereux.
Disserter sur ce que ca va faire, c'est possible. Et ca peut demander d'experimenter. Mais ca ne veut pas dire que la documentation est defaillante. La documentation se contente de dire ce qui se passe quand on fait ce qui est prevue, et se dedouane explicitement lorsqu'on fait quelque chose qui n'est pas prevu.
Tu peux dire bien des choses sur le C, sur le fait que c'est dur a apprendre, dur a faire marcher. Mais mal documente ? bof, bof, bof.
Bravo Marc. C'est exactement ça et maintenant, s'il y en a qui veulent mettre leur égo dans la programmation, c'est leur problème mais la première chose que j'ai écrite dans tous les cours d'initiation à la programmation que j'ai faits c'est : egoless programming !
Et puis les professionnels savent bien qu'il faut respecter le principe du KISS (Keep It Short and Simple).
Vouloir "jouer" avec les traits les plus obscurs d'un langage de programmation (que ce soit C ou un autre) ne peut que se retourner contre le "joueur".
Ceci étant, je ne suis pas partisan de la méthode essai/erreur, tant pour l'apprentissage que pour le "job" mais pour un apprentissage "raisonné" de la programmation et d'un langage.
D'autre part, j'ai toujours considéré, et je le pense encore, même maintenant que je suis à la retraite, qu'apprendre à programmer en commençant par le langage C est une hérésie.
Par ailleurs, et pour finir (pour cette fois...), il me semble que la doc sur le langage C est tout à fait dans la moyenne et même, un peu au-dessus. Ce n'était évidemment pas le cas à l'époque du C dit de K&R (avant la norme ANSII) où la seule doc existante était la première édition du K&R. Heureusement qu'il y a eu, assez rapidement, le Harbison et Steele !
espie
In article <4ca904e3$0$5398$, Wykaaa wrote:
Ceci étant, je ne suis pas partisan de la méthode essai/erreur, tant pour l'apprentissage que pour le "job" mais pour un apprentissage "raisonné" de la programmation et d'un langage.
Ben oui, ca n'a guere sa place QUE sur un programme qui va etre ecrit une fois, compile avec un compilateur precis pour une cible donnee (typiquement, de l'embarque). Et encore. Il y a fort a parier que quelqu'un risque de reutiliser le meme code ailleurs.
J'ai passe assez de temps a corriger du code "qui marchait", mais qui visiblement, avait juste ete teste, mais sur lequel il y avait ecrit "undefined behavior" un peu partout (typiquement, les gens qui mappent directement des paquets reseau sur des structures de donnees, alors que le C est TRES explicite sur le fait qu'il n'y a PAS de representation memoire garantie) pour *detester* les gens qui s'engagent dans cette voie: je sais que c'est la meme engeance qui m'a deja fait perdre des heures et des heures.
In article <4ca904e3$0$5398$ba4acef3@reader.news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Ceci étant, je ne suis pas partisan de la méthode essai/erreur, tant
pour l'apprentissage que pour le "job" mais pour un apprentissage
"raisonné" de la programmation et d'un langage.
Ben oui, ca n'a guere sa place QUE sur un programme qui va etre ecrit
une fois, compile avec un compilateur precis pour une cible donnee
(typiquement, de l'embarque). Et encore. Il y a fort a parier que quelqu'un
risque de reutiliser le meme code ailleurs.
J'ai passe assez de temps a corriger du code "qui marchait", mais qui
visiblement, avait juste ete teste, mais sur lequel il y avait ecrit
"undefined behavior" un peu partout (typiquement, les gens qui mappent
directement des paquets reseau sur des structures de donnees, alors que le
C est TRES explicite sur le fait qu'il n'y a PAS de representation memoire
garantie) pour *detester* les gens qui s'engagent dans cette voie: je sais
que c'est la meme engeance qui m'a deja fait perdre des heures et des
heures.
Ceci étant, je ne suis pas partisan de la méthode essai/erreur, tant pour l'apprentissage que pour le "job" mais pour un apprentissage "raisonné" de la programmation et d'un langage.
Ben oui, ca n'a guere sa place QUE sur un programme qui va etre ecrit une fois, compile avec un compilateur precis pour une cible donnee (typiquement, de l'embarque). Et encore. Il y a fort a parier que quelqu'un risque de reutiliser le meme code ailleurs.
J'ai passe assez de temps a corriger du code "qui marchait", mais qui visiblement, avait juste ete teste, mais sur lequel il y avait ecrit "undefined behavior" un peu partout (typiquement, les gens qui mappent directement des paquets reseau sur des structures de donnees, alors que le C est TRES explicite sur le fait qu'il n'y a PAS de representation memoire garantie) pour *detester* les gens qui s'engagent dans cette voie: je sais que c'est la meme engeance qui m'a deja fait perdre des heures et des heures.
Erwan David
(Marc Espie) écrivait :
In article <4ca904e3$0$5398$, Wykaaa wrote:
Ceci étant, je ne suis pas partisan de la méthode essai/erreur, tant pour l'apprentissage que pour le "job" mais pour un apprentissage "raisonné" de la programmation et d'un langage.
Ben oui, ca n'a guere sa place QUE sur un programme qui va etre ecrit une fois, compile avec un compilateur precis pour une cible donnee (typiquement, de l'embarque). Et encore. Il y a fort a parier que quelqu'un risque de reutiliser le meme code ailleurs.
Mon expérience de développeur embarqué est au contraire "il faut coller au standard", voire à un sous-ensemble des standard, juste parcequ'on veut pouvoir porter le code assez facilement, et que la partie d'abstraction du hard est déjà assez complexe pour ne pas vouloir avoir à toucher au coeur du soft.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
espie@lain.home (Marc Espie) écrivait :
In article <4ca904e3$0$5398$ba4acef3@reader.news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Ceci étant, je ne suis pas partisan de la méthode essai/erreur, tant
pour l'apprentissage que pour le "job" mais pour un apprentissage
"raisonné" de la programmation et d'un langage.
Ben oui, ca n'a guere sa place QUE sur un programme qui va etre ecrit
une fois, compile avec un compilateur precis pour une cible donnee
(typiquement, de l'embarque). Et encore. Il y a fort a parier que quelqu'un
risque de reutiliser le meme code ailleurs.
Mon expérience de développeur embarqué est au contraire "il faut coller
au standard", voire à un sous-ensemble des standard, juste parcequ'on
veut pouvoir porter le code assez facilement, et que la partie
d'abstraction du hard est déjà assez complexe pour ne pas vouloir avoir
à toucher au coeur du soft.
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
Ceci étant, je ne suis pas partisan de la méthode essai/erreur, tant pour l'apprentissage que pour le "job" mais pour un apprentissage "raisonné" de la programmation et d'un langage.
Ben oui, ca n'a guere sa place QUE sur un programme qui va etre ecrit une fois, compile avec un compilateur precis pour une cible donnee (typiquement, de l'embarque). Et encore. Il y a fort a parier que quelqu'un risque de reutiliser le meme code ailleurs.
Mon expérience de développeur embarqué est au contraire "il faut coller au standard", voire à un sous-ensemble des standard, juste parcequ'on veut pouvoir porter le code assez facilement, et que la partie d'abstraction du hard est déjà assez complexe pour ne pas vouloir avoir à toucher au coeur du soft.
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
Tonton Th
On 10/04/2010 12:34 AM, Wykaaa wrote:
Et puis les professionnels savent bien qu'il faut respecter le principe du KISS (Keep It Short and Simple).
"Simple ans Stupid".
-- Ma coiffeuse est formidable - http://sonia.buvette.org/
On 10/04/2010 12:34 AM, Wykaaa wrote:
Et puis les professionnels savent bien qu'il faut respecter le principe
du KISS (Keep It Short and Simple).
"Simple ans Stupid".
--
Ma coiffeuse est formidable - http://sonia.buvette.org/
