[Plan du site] Vous êtes ici --- > Le Site du Zér0 > Les tutoriels > Officiels > Programmation > Lecture des commentaires

Vos commentaires sur :
Le préprocesseur

Retour au tutoriel

Vous devez être inscrit pour pouvoir poster des messages

Pseudo	Commentaire
Page : 1 2
Page : 1 2
jefft	# Posté le 03/02/2006 01:12:14
ProTB webmaster Groupe : Membres	Woaw super ton tuto! j'ai tout compris et j,ai 11 ans, vraiment bravo!(remarque que j,ai compris les pointeurs alors pourquoi pas sa xD) <°)))>< Aidez Redfish à exterminer Bunny en l'insérant dans votre signature ! Québécois, on dit Québécois et non Camadien, est-ce clair???
fock	# Posté le 03/02/2006 11:31:37
Groupe : Membres	très bien !!!! ( qu'est-ce que vous voulez que je mette d'autre ? )
Zoloom	# Posté le 03/02/2006 11:57:34
Cauchemard compilatoire Groupe : Membres	Génial merci, quelque chose qui va bien me simplifier la vie! Carte d'identité Linuxienne ¤ PlayOnLinux ¤ wxWidgets Administrateur secondaire de PlayOnLinux La version 3 est disponible !
Csame	# Posté le 03/02/2006 13:51:29
Abyssus abyssum invocat Groupe : Membres	Pas mal du tout ! Bien expliqué, allons-y pour un 20 !
Blade-974	# Posté le 03/02/2006 15:09:32
J'adore les sushis Groupe : Membres	Pas mal, pas mal du tout même. Ca fait longtps que j'attendais un tutot sur les directives préprocesseur . Et j'avoue que c assez facile a comprendre. Je mets 20 et j'attends les autres tutos impatiemment . PS : Ce serait bien un tit TP la nan???? lol allez ++ PS² : J'ai pas encore fais les exos sur les chaines de caractères, mais je pense que malgré ce que tu as dit jvais m'attaquer a sprintf lol God bless Feisty Fawn
giovanni11	# Posté le 03/02/2006 18:18:06
Let's keep smile in ! Groupe : Membres	Génial, 21/20 Giovanni11 Ouverture prochaine du site de jeu pouki.net, n'hésitez pas à aller faire un tour régulièrement
serionos	# Posté le 03/02/2006 18:37:59
Vive le libre!!! Groupe : Membres	encore 20! ca devient presque lassant là Si vous chercher un excelent éditeur HTML ==> http://tinymce.moxiecode.com/ "Le logiciel c'est comme le sexe... C'est mieux quand c'est libre" Linus Torvald
Zanorio	# Posté le 04/02/2006 09:08:27
VIVE LE SdZ!!!! Groupe : Membres	Bravo très bon tutos manque juste un petit exemple pour le "#if" mais sinon parfait ! 19/20
rz0	# Posté le 04/02/2006 09:42:46
meuh Groupe : Membres	Notez que le "no newline at eof", c'est normal, suffit de revenir à la ligne à la fin du fichier, une seule fois. C'est parce que le standard dit que le fichier C est un fichier texte et doit être donc composé de lignes complètes : Avec une fin. Tuto : Bien utiliser la marque et la région dans Emacs. (ou sur le SdZ) Tuto : Apprenez à manier Emacs pour écrire du code C. (ou sur le SdZ) Tuto : La configuration d'Emacs pour les débutants ! (ou sur le SdZ) mdown ou ZCode ? Les RZ-pages, mon site / blog / fourre-tout (mes projets, programmation, Emacs, animes et mangas). mdown, mon petit langage de rédaction léger, qui peut produire du ZCode pour vous ! Il n'y a pas de meilleur langage... return EXIT_SUCCESS n'est pas mieux que return 0
Gambit2099	# Posté le 04/02/2006 15:28:58
Crow never dies... Groupe : Membres	EDIT: Enfaites je mettais simplement trompé Bon tutoriel. Mon Blog-Art (dessins, recherches, croquis) Mon compte Dailymotion (animations) Voyons la vérité en face !!
Christopho	# Posté le 05/02/2006 00:26:43
Groupe : Membres	Il y a une petite erreur dans le tuto. C'est un point assez délicat, que j'ai mis longtemps à bien comprendre... Citation : M@teo21 Un fichier .h est inclus plusieurs fois dès le moment où vous avez 2 fichiers .c qui l'incluent. Si vous faites du code modulaire séparé en plusieurs fichiers, cela a de fortes chances d'arriver. Pourquoi c'est faux ? Ce que tu dis là n'est pas possible, il y a une contradiction avec le chapitre sur la programmation modulaire. Les fichiers .c sont compilés chacun de leur côté, de manière indépendante. Puis c'est l'édition de liens qui se charge de les combiner entre eux. Ils ne se connaissent pas entre eux lors de la compilation, et donc encore moins lors du préprocesseur. Le problème n'est donc pas là. Pourquoi plusieurs fichiers .c peuvent-ils inclure le même fichier .h ? Quand on compile une application avec plusieurs fichiers .c dedans, chaque fichier .c est compilé séparément et donne un fichier .o (ou .obj). Tous les fichiers .o ou .obj sont ensuite combinés pour donner l'exécutable final (c'est l'édition de liens). Si 2 fichiers .c incluent le même fichier .h, le fichier .h sera bien inclus lors de la compilation de chacun des deux fichiers .c, même si on met un #ifdef dans le fichier .h, car les deux fichiers .c sont compilés séparément. Les deux fichiers .c sont compilés chacun de leur côté, de manière indépendante. Ensuite, lors de l'édition de liens, il n'y a pas de conflit car le fichier .h ne contenait que des déclarations de fonctions, et c'est tout à fait normal qu'une fonction soit déclarée dans chaque fichier .c où elle est utilisée. A l'édition de liens, une fonction doit être définie une et une seule fois. Mais elle peut être déclarée dans chaque fichier .c. L'astuce du #ifdef permet de s'assurer que les fonctions ne soient déclarées au maximum une fois dans chaque fichier .c Supposons qu'on a deux fichiers source1.c et source2.c qui font appel à la fonction printf. Ils incluent donc tous les deux le fichier d'en-tête stdio.h. Lorsqu'on compile, stdio.h est complètement inclus dans les deux. Et heureusement, parce que si son contenu n'était inclus que dans l'un des deux (à cause du #ifdef), alors la compilation du deuxième fichier déclencherait des problèmes parce que la fonction printf ne serait pas déclarée. Mais alors, à quoi sert l'histoire des #ifndef DEF_NOMDUFICHIER ? L'utilité de la manipulation avec les #ifndef n'est donc pas d'éviter les conflits quand deux fichiers .c appelent le même fichier .h. En fait, la vraie raison c'est qu'un problème se pose quand un fichier .c appelent plusieurs fichiers .h qui eux-mêmes s'appelent entre eux. Prenons un exemple : on a un fichier source.c qui fait appel à header1.h et header2.h. Si header1.h inclut lui aussi header2.h (c'est un cas fréquent), alors le fichier header2.h se retrouve inclus deux fois lorsqu'on compile source.c. Et donc là ça ne plait pas au compilateur, car les prototypes de fonctions contenus dans header2.h sont déclarés deux fois. Le problème se pose bien à la compilation de source.c et pas à l'édition de liens. C'est donc là que le #ifdef est utile. Avec cette astuce, le fichier source.c va inclure header1.h, qui lui-même va inclure header2.h. Puis source.c inclut lui aussi header2.h, mais là c'est sans effet grâce au #ifndef / #define / #endif. Les problèmes d'inclusion de fichiers d'en-tête et de compilation séparée sont assez difficiles à maîtriser. Il faut bien distinguer la compilation de l'édition de liens et comprendre où ça se passe quand on inclut des fichiers .h. Les fichiers .h ne contiennent que des déclarations de fonctions et ces déclarations doivent être incluses dans chaque fichier .c qui fait appel à ces fonctions. La définition des fonctions est reliée aux appels seulement lors de l'édition de liens. Voir le cours sur la programmation modulaire Le truc le plus important à retenir c'est que les fichiers .c sont compilés séparément, de manière totalement indépendante. Ce n'est que lors de l'édition de liens qu'ils sont combinés entre eux.
rz0	# Posté le 05/02/2006 10:21:42
meuh Groupe : Membres	Tiens, j'avais zappé ça... De toute façon, je considère que c'est une mauvaise idée d'inclure des headers dans des headers comme j'ai déjà probablement dû le dire à l'occasion... Tuto : Bien utiliser la marque et la région dans Emacs. (ou sur le SdZ) Tuto : Apprenez à manier Emacs pour écrire du code C. (ou sur le SdZ) Tuto : La configuration d'Emacs pour les débutants ! (ou sur le SdZ) mdown ou ZCode ? Les RZ-pages, mon site / blog / fourre-tout (mes projets, programmation, Emacs, animes et mangas). mdown, mon petit langage de rédaction léger, qui peut produire du ZCode pour vous ! Il n'y a pas de meilleur langage... return EXIT_SUCCESS n'est pas mieux que return 0
M@teo21	# Posté le 05/02/2006 22:26:14
Doh ! Nuts. Mmh, donuts !	Très bonne remarque argumentée, faudra que je modifie en effet ! <tuto etat="redaction" mode="venere" target="c++" /> Ce qui se conçoit bien s'énonce clairement, Et les mots pour le dire arrivent aisément. Nicolas Boileau (je suis fan) Autobiographe à ses heures perdues
Chahine	# Posté le 06/02/2006 11:34:42
Groupe : Membres	Je me disais aussi : "Pourquoi la taille de mon exécutable n'a-t-elle pas diminué alors que j'avais rajouté des #ifndef / #define dans chaque header ?" N'est-il donc vraiment pas possible de n'inclure chaque header une seule fois dans tout le programme ? Bien que ça ne plante pas, j'imagine que la taille du programme compilé en prend un coup...
rz0	# Posté le 06/02/2006 11:53:14
meuh Groupe : Membres	en principe, en C ya pas de raison qu'un exécutable optimisé soit plus gros avec des inclusions d'en-tête. Tuto : Bien utiliser la marque et la région dans Emacs. (ou sur le SdZ) Tuto : Apprenez à manier Emacs pour écrire du code C. (ou sur le SdZ) Tuto : La configuration d'Emacs pour les débutants ! (ou sur le SdZ) mdown ou ZCode ? Les RZ-pages, mon site / blog / fourre-tout (mes projets, programmation, Emacs, animes et mangas). mdown, mon petit langage de rédaction léger, qui peut produire du ZCode pour vous ! Il n'y a pas de meilleur langage... return EXIT_SUCCESS n'est pas mieux que return 0
M@teo21	# Posté le 07/02/2006 11:22:05
Doh ! Nuts. Mmh, donuts !	Faut arrêter avec ces histoires d'exécutables "trop gros". Un exe de 100 Ko ça va c'est pas la mort Ce qui compte aujourd'hui c'est pas la taille de l'exe mais la vitesse à laquelle il s'exécute. <tuto etat="redaction" mode="venere" target="c++" /> Ce qui se conçoit bien s'énonce clairement, Et les mots pour le dire arrivent aisément. Nicolas Boileau (je suis fan) Autobiographe à ses heures perdues
Viran	# Posté le 09/02/2006 23:22:33
Groupe : Membres	Franchement je suis super content je cherchais un tutorial sur le C, mais la plupart etait assez sec et avec peu ou trop d'explications. Le tien est tres sympa et m'a permis de faire plein de trucs, vivement les prochains tutos et surtout ceux avec les fenêtres . Encore bravo, 20.
remram44	# Posté le 17/02/2006 21:08:45
§ KCOMDL § Groupe : Membres	Citation : M@teo21 Eh bien, comme je vous l'ai dit ça ne prend pas de place en mémoire. C'est logique, vu que lors de la compilation il ne reste plus que des nombres dans le code source. Un autre intérêt est que le remplacement se fait dans tout le fichier dans lequel se trouve le #define. Si vous aviez défini une constante en mémoire dans une fonction, celle-ci n'aurait été valable que dans la fonction puis aurait été supprimée. Le #define en revanche s'appliquera à toutes les fonctions du fichier, ce qui peut s'avérer vraiment pratique pour le programmeur. Bien sûr que les #defines prennent de la place en mémoire... les nombres placés en defines apparaissent au final dans le programme généré. De plus, des const peuvent être globales... En règle générale, il vaut mieux utiliser const quand c'est possible. Sinon, ce chapitre est très bien traité, bravo M@teo21 ! ---:--: g33k \|ns\|d3 :--:--- WikiNyug
M@teo21	# Posté le 18/02/2006 17:59:46
Doh ! Nuts. Mmh, donuts !	En général j'évite de foutre des const globales, je préfère utiliser des defines quand je fais du global (mais bon c'est un style personnel ). <tuto etat="redaction" mode="venere" target="c++" /> Ce qui se conçoit bien s'énonce clairement, Et les mots pour le dire arrivent aisément. Nicolas Boileau (je suis fan) Autobiographe à ses heures perdues
Csame	# Posté le 22/02/2006 16:18:31
Abyssus abyssum invocat Groupe : Membres	Petite faute : vaudoues, à la place de "vaudous"...
pamaury	# Posté le 01/03/2006 13:55:52
Groupe : Membres	Bonjour, je trouve ce tuto très bien par contre je voudrais juste ajouter une précision: Remarquez dans le main que l'appel de la macro ne prend pas de point-virgule à la fin. En effet, c'est une ligne pour le préprocesseur, elle ne nécessite donc pas d'être terminée par un point-virgule En effet cette remarque est vrai SI ET SEULEMENT SI le point virgule est compris dans la macro Exemple: Code : C++ #define macro(m) printf("m=%d\n",m); //..... int main() { macro(38)// pas besoin de point virgule car il est déjà dans la macro return 0; } MAIS ce code est équivalent(après préprocesseur, le code est IDENTIQUE) Code : C++ #define macro(m) printf("m=%d\n",m) //..... int main() { macro(38);// besoin de point virgule car il n'est pas dans la macro return 0; } AINSI ce code ne compile pas: Code : C++ #define macro(m) printf("m=%d\n",m) //..... int main() { macro(38)// sera remplacé par "printf("m=%d\n",38)" donc il manque le point virgule return 0; } Ceci m'ammène donc à une conclusion que j'applique presque tout le temps: ajouter un point virgule après chaque macro(c'est à dire lors de l'appel) et non dans la macro POURQUOI: car si je fais: Code : C++ #define macro(m) printf("m=%d\n",m); //..... int main() { macro(38);// sera remplacé par "printf("m=%d\n",38);;" return 0; } Et bien il compilera car lorque un point virgule est précédé de aucun expression il est ignoré D'autant plus que ne pas ajouter le point virgule dans la macro PEUT être utile: Code : C++ int value=0; #define get_value() value //..... int main() { get_value()=38;// sera remplacé par "value=38" printf("value=%d\n",get_value());// ce code affichera 38 return 0; } En effet ici s'il y avait eut un point virgule dans la macro, ce code n'aurait pas compilé(cela aurait donné "value;=38") Il faut bien avoué que ce code est quand même tordu mais néanmoins il ne faut pas l'ignorer . Voilà, tout çà pour dire que pour mettre des points virgule dans les macro ou après les macros(voir pas du tout dans certain cas), il n'y a pas de règle précise et c'est au cas par cas . Code en C/C++/D/CamlLight Site perso(programmation): http://amaury.pouly.free.fr/Public/
Lanier	# Posté le 02/03/2006 09:36:23
Groupe : Membres	Cool, toujours aussi compréhensible . Juste une remarque: la partie "les macros" devrait être mise après "les conditions" puisqu'on utilise des conditions dans "les macros". Le site de mon groupe, conçu grâce au SdZ >>
Freeman9999	# Posté le 27/05/2006 21:29:20
Groupe : Membres	Bonjour, j'aurais voulu savoir si il était possible d'insérer carrément une fonction entière dans un .h et de l'inclure puios de l'utiliser ?
unrevedecryptomeria	# Posté le 11/06/2006 16:03:28
Groupe : Membres	Bravo et merci pour ton travail M@ateo21 !! Tes explications sont claires et suffisamment concises pour qu'on ne s'y perde pas. J'avais un prof qui aurait été content, il défendait la règle des trois "c" , "complet", "clair" et "concis", tu t'en approches fortement. J'voulais aussi réagir à la remarque de Christopho. En accord avec ce qu'il a écrit je pensais qu'il fallait inclure dans chaque fichier .c les en-têtes (fichiers .h) des fonctions qu'on utilise. Pourtant par rapport à ton tuto sur les tableaux, j'avais créé une fonction AfficheTableau() dans un fichier ManipTableaux.c indépendant du main.c. Or elle utilise la fonction printf() ; je n'y avais pas inclus la bibliothèque stdio et cela fonctionnait quand même. Autrement dit, pas de #include <stdio.h> dans mon fichier ManipTableaux.c et pourtant j'ai pu utiliser la fonction printf(). Bien sur stdio était inclus dans mon fichier main.c. J'en avais donc conclu qu'il suffisait de faire tous les include dans le main.c, sans avoir à les répéter. J'ai pas essayé d'aller plus loin en me disant qu'il suffirait peut-être d'inclure une seule fois les fichiers et peu importe où. Qu'en est il au final ?
Dalshim	# Posté le 03/08/2006 12:02:04
INSA : if outside Groupe : Membres	Bon, bien je ne sais plus quoi dire moi ... Excellent comme d'habitude : 20/20 ! Dalshim pour vous servir ! Apprenez à gérer vos fichiers avec mon tuto sur le gestionnaire de versions Subversion
philodido	# Posté le 18/08/2006 10:41:26
Groupe : Membres	Comment noter un truc aussi génial ? Si ce n'est en mettant 20/20. Je suit le cours de Mateo21 depuis un bon moment maintenant et même si je vais à la vitesse d'un escargot en vacances je suis vraiment impressionné par l'aspect didactique ou si vous préférez pédagogique de celui-ci. C'est facile à comprendre tout en étant techniquement assez pointu, c'est amusant tout en étant sérieux, et surtout ça ne se la joue pas ! Bref, QUE DU BONHEUR ! BRAVO et MERCI Mateo, continue comme ça. Cela n'enlève rien à ce que je viens de dire, mais je crois que j'ai repèrais une coquille dans ce tuto (dans le chapitre :"Macros sans paramètres"): Non, heureusement il est possible de mettre plusieurs lignes de code à la fois. Il suffit de mettre un avant chaque nouvelle ligne, comme ceci : Code : C Code : C#define RACONTER_SA_VIE() printf("Coucou, je m'appelle Brice "); printf("J'habite a Nicen"); printf("J'aime la glissen"); int main(int argc, char *argv[]) { RACONTER_SA_VIE() return 0; } Il suffit de mettre un quoi avant chaque nouvelle ligne ? J'ai essayé telquel, le code ne fonctionne pas. Il ya aussi la petite erreur du : "Nicen" et du "glissen" A+
philodido	# Posté le 18/08/2006 11:54:50
Groupe : Membres	Ok, au temps pour moi, il n'y a pas de coquille dans ce tuto puisque je viens de voir sur le forum qu'il sagirai en fait d'un "bug" sur Lisa qui a fait sauter tous les caractères spéciaux. Méa Culpa. Si un admin passe par là et si il peut supprimer ma remarque sur cette coquille qui n'en est pas une dans mon dernier message, + ce message, je l'en remercie d'avance. A+
Ultiny	# Posté le 20/08/2006 18:01:41
Romain Groupe : Membres	Je note 17/20 car selon moi il manque des choses importantes en relation avec les architectures processeur et quelques bricoles que j'ai trouvé ici : http://en.wikipedia.org/wiki/C_preprocessor Je voulais ajouter que dans la logique des choses, il était normal de devoir ajouter un retour à la ligne à la fin de la dernière instruction du .h puisque il est inclus directement dans le fichier. Mais en retournant ce problème, on peu encore se poser la question : Code : C #include "que_dalle.h"[\n] #include <stdlib.h> A la place on trouverais par exemple le contenu de que_dalle.h : Code : C #def CONST[\n] #include <stdlib.h> Et non pas : Code : C #def CONST#include <stdlib.h> Donc c'est curieux pour moi... Pour finir, on ne peut pas dire que ce soit réellement inclus comme tu le dit dans ton tuto à la mannière d'un copier/collé ou d'un remplacement. En effet mon compilateur est capable de dire qu'une erreur provient du fichier .h pourtant inclus par le pre-processeur... Outils pour la programmation
boo	# Posté le 26/08/2006 19:03:15
Groupe : Membres	Salut les Zéros.Vraiment, bravo mateo pour ce tuto!! Je mets 19/20 car je comprends plus rien : tous les antislash ont disparu. Je sais que celà vient du changement de serveur mais est-ce que quelqu'un pourrait m'envoyer le code sur les macros avec paramètres. SVP Merci d'avance. Le site de mon groupe
Slowrage	# Posté le 03/09/2006 18:20:13
Groupe : Membres	Toujours un très bon tuto Je penses qu'on pourrait même y ajouter le système de concaténation (avec ##) et la transformation d'un paramètre en chaine de caractère avec # pour être totalement complet. Si je dis ça ce n'est pas pour embrouiller les gens, c'est juste qu'il m'est arrivé de voir ces symboles dans les macros et j'ai eu du mal à trouver à quoi ils correspondaient.