turpitudes du c : prototype de fonction erreur de code ou erreur avec l'ide geany sur ubuntu
Le
bpascal123
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 of type
‘char *’
Compilation finished successfully.
Je répète des exercices beaucoup de fois avec des noms de variables ou
fonctions différents alors peut-être (très probablement) j'ai déj=
à
utilisé le nom CheckFile comme nom de fonction. Mais aucun souvenir
d'y avoir déclaré une structure comme paramètre Mon ide est geany.
Peut-être CheckFile est dans le cache de l'ide???
Ce qui me fait supposer que ça vient de l'ide est que si je change de
nom, par exemple : CheckMyFile, ça fonctionne sans messages
Quelqu'un quelque part peut-il m'expliquer?
Merci,
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 of type
‘char *’
Compilation finished successfully.
Je répète des exercices beaucoup de fois avec des noms de variables ou
fonctions différents alors peut-être (très probablement) j'ai déj=
à
utilisé le nom CheckFile comme nom de fonction. Mais aucun souvenir
d'y avoir déclaré une structure comme paramètre Mon ide est geany.
Peut-être CheckFile est dans le cache de l'ide???
Ce qui me fait supposer que ça vient de l'ide est que si je change de
nom, par exemple : CheckMyFile, ça fonctionne sans messages
Quelqu'un quelque part peut-il m'expliquer?
Merci,
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
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.
#include */
#include
#define CRECMAX 10 /* nbr d'enreg. max */
#define CTXTMAXL 20 /* long. de caracteres max */
void OpenFileM(FILE *FP_FILE) ;
int main(void)
{
FILE *MP_SOURCE = NULL ;
FILE *MP_DESTI = NULL ;
char MPSource[] = "/media/XP/code_c/data15a.txt" ;
char MPDesti[] = "/media/XP/code_c/data15rev.txt" ;
printf("nOuverture de "data15a.txt" : n") ;
MP_SOURCE = fopen(MPSource, "r") ;
OpenFileM(MPSource) ;
printf("nn") ;
return 0 ;
}
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
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
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 ...
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 !
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.
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é
"Simple ans Stupid".
--
Ma coiffeuse est formidable - http://sonia.buvette.org/