Bonjour cyberespace,
je viens de me rendre compte que quand je déclare 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 ÂmainÂ:
exPract1.c:15: note: expected Âstruct FILE *Â but argument is o f type
Âchar *Â
Bonjour cyberespace,
je viens de me rendre compte que quand je déclare 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 ÂmainÂ:
exPract1.c:15: note: expected Âstruct FILE *Â but argument is o f type
Âchar *Â
Bonjour cyberespace,
je viens de me rendre compte que quand je déclare 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 ÂmainÂ:
exPract1.c:15: note: expected Âstruct FILE *Â but argument is o f type
Âchar *Â
En fait ce n'est pas un langage qui permet tant
d'expérimentation pour être honnête
En fait ce n'est pas un langage qui permet tant
d'expérimentation pour être honnête
En fait ce n'est pas un langage qui permet tant
d'expérimentation pour être honnête
"" 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.
"bpascal123@googlemail.com" <bpascal123@googlemail.com> 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.
"" 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.
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 ...
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 ...
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 ...
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.
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.
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.
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.
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.
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.
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.
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.
Et puis les professionnels savent bien qu'il faut respecter le principe
du KISS (Keep It Short and Simple).
Et puis les professionnels savent bien qu'il faut respecter le principe
du KISS (Keep It Short and Simple).
Et puis les professionnels savent bien qu'il faut respecter le principe
du KISS (Keep It Short and Simple).