Version imprimable
Pourquoi ? Il disent que la bibliothèque s'appelle stdio, ce qui n'est faux, et que son interface (synopsis) est contenue dans stdio.h, ce qui n'est pas faux. A aucun moment ils ne disent que stdio.h est la bibliothèque.Citation:
Envoyé par Emmanuel Delahaye
Il y a deux minutes, je me suis dit la même chose... Et puis j'ai eu peur d'être confondu avec un de ces "documents" par Emmanuel...Citation:
Envoyé par DaZumba
Et puis ces "documents"...ça risque d'être dur de les tous les brûler (i.e. : tous leurs exemplaires) : les pages de man, ça ne manque pas vraiment...
Emmanuel: J'ai fait un BTS II avant qu'il ne devienne IRIS, je suppose donc qu'il s'agit d'une série de TP d'initiation au C++, dans le cadre du cours de système. Ceci, après un an ou deux de C.
De mon temps au Lycée Jules Ferry de Versailles (puisse son architecte souffrir les tourments éternels du grand Cthulhu pour son incompétence), le cours d'initiation au C++ était vraiment pauvre et m'en a dégouté direct sur la pensée "Les iostreams, ça marche pas". Il faut dire qu'on ne nous avait appris ni fflush(stdout) (inutile sous DOS), ni l'équivalent C++, std::cout.flush()...
Et aussi, les standards étaient "en option".
J'espère que ça a changé depuis ce temps-là, mais à en juger par le void main(), c'est pas gagné...
Tout celà est très confusant.Citation:
Envoyé par DaZumba
stdio n'est pas une bibliothèque. Ca n'existe pas. Il y a une bibliothèque standard. C'est tout. Son interface est composé d'un certain nombre de fichiers d'entête dont <stdio.h>.
Les implémenteurs s'amusent à inventer des noms, mais rien de tout ça ne figure dans la norme.
On pourrait appeler ça 'section' ou 'module voire 'classe' (le mot est libre en C !)', mais pas 'bibliothèque'.
Ton prof dit un peu n'importe quoi à ce sujet. La fonction main et WinMain doivent toujours renvoyer une valeur au système. En cas de succès, c'est normalement la valeur 0 qui est renvoyée.Citation:
Bon pour la première ligne j'ai trouvé au pif j'ai remplacé "void" par "int" mais alors je comprends pas cette histoire de void, mon prof nous a dit de toujours mettre void main() car c'est comme une fonction mathématique nous a t-il dit mais il a pas dévellopé pluss
Donc, ne pas écrire :
mais :Code:
2
3
4
Code:
2
3
4
5
Le propre d'une fonction est de renvoyer une valeur. Sinon c'est une procédure.
8O 8O Pas de procédures en C. Que des fonctions, même celles qui ne retournent pas de valeur.Citation:
Envoyé par Aurelien.Regat-Barrel
C != Pascal.
Pascal <> C
edit : Argh, je croyais toujours être le sur le forum C... mais je pense que c'est pareil en C++.
Dans la tradition C (et C++ en fait partie) comme dans la tradition des langages fonctionnels, tout est fonction. En Algol, tout est procédure. En Pascal on a des fonctions et des procédures. En Fortran des fonctions et des sous-routines. Ce n'est qu'une nomenclature et j'ai pas l'impression qu'il y en a une qui soit plus établie qu'une autre (et s'il y en a une, c'est plutôt le tout est fonction).Citation:
Envoyé par Aurelien.Regat-Barrel
1/ En C comme en C++, le type de retour de main, c'est int et pas autre chose.Citation:
Envoyé par ch3ch3
2/ Ton environnement de développement est incohérent. D'un côté ton éditeur a l'air de considérer '\n' (qu'il soit représenté par CR, CR-CL ou LF) comme un séparateur de ligne et ne t'en met donc pas à la fin de la dernière ligne; de l'autre le compilateur le considère comme une marque de fin de ligne, donc il t'averti que la dernière ligne n'est pas terminée. Si tu utilises un environnement intégré, ça mérite un rapport de bug...
En C, je te crois sur parole. Si on se situe au niveau génie logiciel / théorie des langages, ce qui distingue une procédure d'une fonction, c'est qu'une fonction peut être utilisée pour construire une expression, du genre:Citation:
Envoyé par Emmanuel Delahaye
a = sin( b ) + cos( c );
et doit donc pour cela renvoyer une valeur.
En C, les procédures (niveau GL) sont simulées via des fonctions (niveau C) qui ne renvoient rien, un peu comme l'héritage C++ privé est utilisé pour faire de la composition. Au niveau GL, c'est de la composition. Au niveau C++, de l'héritage.
Enfin bref, si je suis intervenu, c'est pas pour relever le terme de fonction C, mais celui de "fonction mathématique", donc devant renvoyer une valeur, ce qui est en contradiction avec le "void main() car c'est comme une fonction mathématique".
De toute façon, j'ai appris à haïr la distinction fonction-procédure: Car c'est avec ces c****ies qu'on se retrouve avec des "fonctions" qui n'ont pas le droit d'avoir le moindre effet de bord (y compris la saisie de valeurs) et des "programmes" qui n'ont pas le droit de retourner de valeur.
Dans ces langages, si tu veux faire un programme qui a un effet de bord et te dit le résultat, tu es obligé de passer par des variables globales...
Une des choses que j'aime le moins en Ada; mais il y a d'autres moyens que les variables globales, soit faire une procédure, soit passer un pointeur -- après tout c'est ce qu'on fait en C. Le plus emm... c'est encore quand on est en train de s'interfacer avec une lib écrite dans un langage n'ayant pas cette contrainte.Citation:
Envoyé par Médinoc
Salut,
Cet avertissement est typique, sous code::bloks, quand il n'y a pas une ligne vide apres la dernière ligne significative du fichierCitation:
Envoyé par Jean-Marc.Bourguet
En attendant que ce soit résolu, il suffit tout simplement de rajouter une ligne vide tout en bas des fichiers
Ca ne résoudra évidemment en rien le problème que main doit renvoyer un int, mais ca supprimera l'avertissement ;)
D'ailleurs, bizarrement MinGW Developer Studio donne le même avertissement si on ne met pas de ligne vide à la fin.
Je viens d'envoyer un rapport de bug pour code::blocks, mais ce que tu dis me ferais plutot penser à un problème du parseur de gcc...
si Jean-Marc.Bourgue peut confirmer qu'il ne faut pas *forcement* une ligne vide en fin de fichier, on fera remonter le bug vers les dev GCC qui seront peut etre plus aptes à le résoudre ;)
La norme stipule qu'une ligne compléte doit être terminée par un saut de ligne.Citation:
Envoyé par koala01
c'est traité dans la FAQ C
http://c.developpez.com/faq/c/?page=...VERS_nonewline
La norme... commence par dire que la première phase c'est de transformer la représentation externe en une représentation interne et entre autres les "marques de fin de ligne" par des \n. Donc l'important est de savoir quelles sont les conventions de l'OS. Si celles-ci marquent les lignes par un caractère -- ce qui n'est pas obligatoire et il y a des OS qui ont d'autres conventions -- il faut savoir si ce caractère est un séparateur (auquel cas il n'est pas possible de considérer que la dernière ligne n'est pas terminée) ou une marque de fin de ligne (auquel cas c'est possible).
A voir une discussion en cours sur comp.std.c++ (New-line fight: Comment -vs- the end of source file), Windows a l'air d'être plus ou moins incohérent en la matière, certains utilitaires prenant une interprétation, d'autres une autre. De toute façon, un environnement intégré comme CodeBlocks devrait respecter ce que fait le compilateur sous-jacent et le pas créer de fichiers qui causent un warning (avec emacs, je peux le faire mais je dois le faire exprès, avec vi je suis incapable de le faire mais je ne suis pas un expert de vi).
Je vois que le sujet fait polémique en tout cas le programme fonctionne donc pour l'instant je me pose pas trop de questions, surtout que ça a l'air compliqué tout ça je vous remercie tous d'avoir répondu très activement =).
Dans le cas précis du warning "no newline at end of file", il suffirait qu'il ajoute systématiquement un retour à la ligne à la fin du fichier lors de l'enregistrement.Citation:
Envoyé par Jean-Marc.Bourguet