IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

 C Discussion :

Appel de fonctions externes Code::blocks


Sujet :

C

  1. #1
    Rédacteur
    Avatar de Zavonen
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    1 772
    Détails du profil
    Informations personnelles :
    Âge : 76
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 1 772
    Points : 1 913
    Points
    1 913
    Par défaut Appel de fonctions externes Code::blocks
    Bonjour à tous,
    J'ai par le passé programmé en C avec Visual Studio.
    Aujourd'hui j'utilise l'EDI Code::blocks 13.12 sous Ubuntu 14.04

    Je souhaite regrouper mes variables globales dans un header intitulé 'globals.h'.
    Un fichier 'globals.c' est prévu, entre autre pour une fonction d'initialisation de ces variables.
    Le fichier contenant, global.h, main.cpp, globals.c appartiennent tous au projet.
    Voici globals.h
    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    #ifndef GLOBALS_H_INCLUDED
    #define GLOBALS_H_INCLUDED
    #include "bird.h"
     
    struct Bird Oiseau;
    int Resolx,Resoly;
    void InitGlobals();
     
    #endif // GLOBALS_H_INCLUDED

    Voici le fichier globals.c
    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
    #include "globals.h"
    void InitGlobals()
    {
        Resolx=640;
        Resoly=480;
    };

    Enfin voici le début du fichier principal

    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
     
    #ifdef __cplusplus
    #include <cstdlib>
    #else
    #include <stdlib.h>
    #endif
     
    #include <SDL/SDL.h>
    #include "globals.h"
     
    int main ( int argc, char** argv )
    {
        InitGlobals();
        // initialize SDL video
        if ( SDL_Init( SDL_INIT_VIDEO ) < 0 )
        {
            printf( "Unable to init SDL: %s\n", SDL_GetError() );
            return 1;
        }

    Lors de la compilation un module objet globals.0 est créé correspondant à la compilation du fichier globals.c

    Mais lorsqu'on active la commande 'build' ou 'rebuild' on a l'erreur suivante:
    ||=== Build: Debug in Flappy (compiler: GNU GCC Compiler) ===|
    /home/gilles/Documents/projets-C/Flappy/main.cpp|14|référence indéfinie vers « InitGlobals() »|
    ||=== Build failed: 1 error(s), 0 warning(s) (0 minute(s), 0 second(s)) ===|

    Qui semble indiquer un problème de linkage main ne trouve pas la définition de InitGlobals(). Je ne sais comment sortir de là.
    Si quelqu'un peut m'indiquer la nature du problème, il me semble que les fonctions C sont extern par défaut. Le prototype est bien dans le header inclus pour vérifier que l'appel est correct. C'est bien la définition de InitGlobals qui n'est pas trouvée. c'est le boulot du linker.
    Je ne comprends pas...
    Ce qu'on trouve est plus important que ce qu'on cherche.
    Maths de base pour les nuls (et les autres...)

  2. #2
    Rédacteur
    Avatar de Zavonen
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    1 772
    Détails du profil
    Informations personnelles :
    Âge : 76
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 1 772
    Points : 1 913
    Points
    1 913
    Par défaut Infos supplémentaires
    Ayant cherché tout l'après-midi j'ai retrouvé ce même problème de nombreuses fois sur d'autres forums. Jamais pu lire la solution...
    D'autres personnes signalent qu'en mettant un #include d'un .c cela fonctionne. c'est vrai, je l'avais remarqué mais c'est contraire aux principes de la modularité du C.
    En outre quand je reprends d'anciens projets Code::blocks multi-fichiers ils ne se compilent plus avec le même problème (impossibilité de trouver les def des fonctions externes dans les modules objets).
    Je pense de plus en plus que c'est un bug énorme de la version 13.12.
    Ce qu'on trouve est plus important que ce qu'on cherche.
    Maths de base pour les nuls (et les autres...)

  3. #3
    Expert confirmé
    Avatar de gerald3d
    Homme Profil pro
    Conducteur de train
    Inscrit en
    Février 2008
    Messages
    2 291
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : France, Côte d'Or (Bourgogne)

    Informations professionnelles :
    Activité : Conducteur de train
    Secteur : Transports

    Informations forums :
    Inscription : Février 2008
    Messages : 2 291
    Points : 4 941
    Points
    4 941
    Billets dans le blog
    5
    Par défaut
    Peut-être qu'effectivement Code::blocks ne recherche pas les entêtes dans le répertoire courant. Essayes lorsque tu fais #include de spécifier le chemin complet du fichier pour voir si ca améliore un peu les choses...

  4. #4
    Rédacteur
    Avatar de Zavonen
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    1 772
    Détails du profil
    Informations personnelles :
    Âge : 76
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 1 772
    Points : 1 913
    Points
    1 913
    Par défaut
    Merci Gerald,
    Mais mon problème n'est pas un problème d'inclusion. Ce n'est pas un problème de compilation (en cas de header introuvable les messages sont distincts et la compilation est impossible). Or les modules objets sont construits, c'est une erreur de linkage, le linker n'arrive pas à fabriquer l'exécutable peut-être pour un problème de chemins.
    En fait mes fichiers objets sont dans /obj/Debug et j'ai l'impression que la recherche est faite dans /obj/Debug/obj/Debug qui n'existe pas. J'ai essayé de trouver des solutions dans le cadre de l'interface CB pour joindre au projet les modules objets soit par adressage direct, soit par adressage absolu. Sans succès !
    Voici l'erreur obtenue quand j'ajoute au projet explicitement :les fichiers objets (puisqu'il ne les trouve pas ...)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
     
     
    -------------- Clean: Debug in Flappy (compiler: GNU GCC Compiler)---------------
     
    Cleaned "Flappy - Debug"
     
    -------------- Build: Debug in Flappy (compiler: GNU GCC Compiler)---------------
     
    gcc -Wall -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -g  -c /home/gilles/Documents/projets-C/Flappy/globals.c -o obj/Debug/globals.o
    g++ -Wall -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -g  -c /home/gilles/Documents/projets-C/Flappy/main.cpp -o obj/Debug/main.o
    g++ -Lobj/Debug -o bin/Debug/Flappy obj/Debug/globals.o obj/Debug/main.o obj/Debug/obj/Debug/globals.o obj/Debug/obj/Debug/main.o  -L/usr/lib/x86_64-linux-gnu -lSDL  
    g++: error: obj/Debug/obj/Debug/globals.o: Aucun fichier ou dossier de ce type
    g++: error: obj/Debug/obj/Debug/main.o: Aucun fichier ou dossier de ce type
    Process terminated with status 1 (0 minute(s), 0 second(s))
    0 error(s), 0 warning(s) (0 minute(s), 0 second(s))
    Nous avons donc deux erreurs, mais le résumé du 'build' est optimiste puisqu'il ne les mentionne pas. Par ailleurs quand j'essaie de lancer une exécution après ce 'build' soit-disant réussi, CB prétend que le projet n'est pas construit et propose ad infinitum de rebâtir l'ensemble.
    Ce qu'on trouve est plus important que ce qu'on cherche.
    Maths de base pour les nuls (et les autres...)

  5. #5
    Rédacteur
    Avatar de Zavonen
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    1 772
    Détails du profil
    Informations personnelles :
    Âge : 76
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 1 772
    Points : 1 913
    Points
    1 913
    Par défaut Code::blocks déblocks !
    Finalement le même code avec un projet Geany, se compile, se construit et s'exécute parfaitement ...
    Il y a donc un problème avec la version 13.12 au moins avec les projets SDL ....mais peut-être aussi avec d'autres, mes anciens projets CB ne se compilent plus alors que l'utilisation directe de gcc ou g++ en ligne de commande marche.
    Dommage, j'avais un bon souvenir de CB.
    Je considère mon problème comme résolu (par abandon).
    Si quelqu'un sait pourquoi CB débloque, je suis preneur.
    Ce qu'on trouve est plus important que ce qu'on cherche.
    Maths de base pour les nuls (et les autres...)

  6. #6
    Responsable 2D/3D/Jeux


    Avatar de LittleWhite
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Mai 2008
    Messages
    26 826
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Mai 2008
    Messages : 26 826
    Points : 218 287
    Points
    218 287
    Billets dans le blog
    117
    Par défaut
    Bonjour,

    Vous avez essayé avec un "rebuild" ?
    Vous avez tenter en recréant le projet ?
    Vous souhaitez participer à la rubrique 2D/3D/Jeux ? Contactez-moi

    Ma page sur DVP
    Mon Portfolio

    Qui connaît l'erreur, connaît la solution.

  7. #7
    Rédacteur/Modérateur
    Avatar de Trap D
    Profil pro
    Inscrit en
    Septembre 2003
    Messages
    4 942
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2003
    Messages : 4 942
    Points : 6 498
    Points
    6 498
    Par défaut
    Bonjour
    J'ai relevé un problème : il me semble que dans le global.h tu définis deux variables Resolx et Resoly et comme global.h est inclus dans plusieurs fichiers, cela fait une multiple définition de variables, cela devrait au moins être signalé et sans doute refusé à la compile.
    Ne devraiet-elles pas être déclarées en extern dans globals.h et définies dans globals.c ?
    "La haine seule fait des choix" - Koan Zen
    "Il ne faut pas être meilleur que les autres, il faut être meilleur que soi." Albert Jacquard
    "Ceux qui savent où ils ont posé leur parapluie ne sont pas alcooliques." - pgibonne.
    Faites du Prolog, ça vous changera les idées !
    Ma page Prolog
    Mes codes sources commentés

    Mon avatar : La Madeleine à la veilleuse de Georges de La Tour

  8. #8
    Rédacteur
    Avatar de Zavonen
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    1 772
    Détails du profil
    Informations personnelles :
    Âge : 76
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 1 772
    Points : 1 913
    Points
    1 913
    Par défaut
    Citation Envoyé par LittleWhite Voir le message
    Bonjour,

    Vous avez essayé avec un "rebuild" ?
    Vous avez tenter en recréant le projet ?
    Oui, oui bien sûr, c'est un réflexe.

    Citation Envoyé par Trap D Voir le message
    Bonjour
    J'ai relevé un problème : il me semble que dans le global.h tu définis deux variables Resolx et Resoly et comme global.h est inclus dans plusieurs fichiers, cela fait une multiple définition de variables, cela devrait au moins être signalé et sans doute refusé à la compile.
    Ne devraiet-elles pas être déclarées en extern dans globals.h et définies dans globals.c ?
    C'est exact mais le fichier est protégé contre les inclusions multiples. ifndef ... etc et encore une fois je n'ai pas de problème de compilation mais de linkage.

    Finalement après un premier essai positif avec geany et gcc, je me retrouve avec le même problème après modification du fichier d'implémentation globals.cpp.
    Autrement dit, la première fois ça marche, et seulement la première fois.
    C'est à devenir fou ...
    Problème non résolu donc.
    Je me demande si la bibliothèque SDL peut-être responsable...
    Ce qu'on trouve est plus important que ce qu'on cherche.
    Maths de base pour les nuls (et les autres...)

  9. #9
    Rédacteur/Modérateur
    Avatar de Trap D
    Profil pro
    Inscrit en
    Septembre 2003
    Messages
    4 942
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2003
    Messages : 4 942
    Points : 6 498
    Points
    6 498
    Par défaut
    Citation Envoyé par Zavonen Voir le message
    C'est exact mais le fichier est protégé contre les inclusions multiples. ifndef ... etc et encore une fois je n'ai pas de problème de compilation mais de linkage.
    Oui et bien, verifie quand même, je viens de faire le test avec un de mes projets, si je mets un gint toto ; dans un .h protégé par un ifndef ... et bien ca ne linke pas, alors que si je mets le extern et definis le toto dans un des .c ça linke !
    "La haine seule fait des choix" - Koan Zen
    "Il ne faut pas être meilleur que les autres, il faut être meilleur que soi." Albert Jacquard
    "Ceux qui savent où ils ont posé leur parapluie ne sont pas alcooliques." - pgibonne.
    Faites du Prolog, ça vous changera les idées !
    Ma page Prolog
    Mes codes sources commentés

    Mon avatar : La Madeleine à la veilleuse de Georges de La Tour

  10. #10
    Rédacteur
    Avatar de Zavonen
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    1 772
    Détails du profil
    Informations personnelles :
    Âge : 76
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 1 772
    Points : 1 913
    Points
    1 913
    Par défaut
    Citation Envoyé par Trap D Voir le message
    Oui et bien, verifie quand même, je viens de faire le test avec un de mes projets, si je mets un gint toto ; dans un .h protégé par un ifndef ... et bien ca ne linke pas, alors que si je mets le extern et definis le toto dans un des .c ça linke !
    Sûr, mais définir des variables communes dans un fichier d'implémentation c'est pas vraiment top.
    Par ailleurs si je fais une inclusion du .c alors ça marche, mais c'est contraire aux principes de modularité et dangereux car mon projet va se complexifier au niveau des inclusions. J'ai essayé également de respécifier 'extern' pour l'appel de InitGlobals, le résultat est le même.
    Ce qu'on trouve est plus important que ce qu'on cherche.
    Maths de base pour les nuls (et les autres...)

  11. #11
    Rédacteur/Modérateur
    Avatar de Trap D
    Profil pro
    Inscrit en
    Septembre 2003
    Messages
    4 942
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2003
    Messages : 4 942
    Points : 6 498
    Points
    6 498
    Par défaut
    Citation Envoyé par Zavonen Voir le message
    Sûr, mais définir des variables communes dans un fichier d'implémentation c'est pas vraiment top.
    Ben si justement, golbal.c me parait in excellent nom pour définir les variables globales.
    J'ai essayé également de respécifier 'extern' pour l'appel de InitGlobals, le résultat est le même.
    c'est dans le .h

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    #ifndef GLOBALS_H_INCLUDED
    #define GLOBALS_H_INCLUDED
    #include "bird.h"
     
    struct Bird Oiseau;
    extern int Resolx,Resoly;
    void InitGlobals();
    et dans le .c :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    #include "globals.h"
    int Resolx,Resoly;
     
    void InitGlobals()
    {
        Resolx=640;
        Resoly=480;
    };
    "La haine seule fait des choix" - Koan Zen
    "Il ne faut pas être meilleur que les autres, il faut être meilleur que soi." Albert Jacquard
    "Ceux qui savent où ils ont posé leur parapluie ne sont pas alcooliques." - pgibonne.
    Faites du Prolog, ça vous changera les idées !
    Ma page Prolog
    Mes codes sources commentés

    Mon avatar : La Madeleine à la veilleuse de Georges de La Tour

  12. #12
    Rédacteur
    Avatar de Zavonen
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    1 772
    Détails du profil
    Informations personnelles :
    Âge : 76
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 1 772
    Points : 1 913
    Points
    1 913
    Par défaut
    Merci pour ton aide.
    Cela fonctionne avec ta suggestion.
    Cependant il y a un truc que je ne pige pas.
    Je n'ai fait des modifs que sur les var Resolx et Resoly, conformément à ta suggestion.
    Le problème portait sur InitGlobals pour cette fonction je n'ai rien changé, ni au prototypage, ni à l'implémentation, et l'erreur a disparu ???
    Ce qu'on trouve est plus important que ce qu'on cherche.
    Maths de base pour les nuls (et les autres...)

  13. #13
    Rédacteur/Modérateur
    Avatar de Trap D
    Profil pro
    Inscrit en
    Septembre 2003
    Messages
    4 942
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2003
    Messages : 4 942
    Points : 6 498
    Points
    6 498
    Par défaut
    C'était le problème de la multidéfinition des variables Resolx et Resoly, elles étaient définies dans plusieurs fichiers. Contrairement à ce que tu penses, si le indef protège contre la multi-inclusion d'un même fichier .h dans un fichier .c, il ne protège pas contre la multi-définition des variables dans les différents .c ou le .h est inclus. Le fichier global.h étant inclus dans différents .c les variables Resol.. étaient définies dans les différents fichiers .c et le compilo merdait. Evidemment, c'est un gros bug de CodeBlocks qui aurait du signaler ce problème. (je crois que Visual C le signale).
    Le fait de déclarer dans le .h les variables comme extern oblige le complio à rechercher ou se trouve la définition des variables.
    A la limite, dans le global.c tu pouvais te limiter à
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    int Resolx = 640,Resoly = 480;
    "La haine seule fait des choix" - Koan Zen
    "Il ne faut pas être meilleur que les autres, il faut être meilleur que soi." Albert Jacquard
    "Ceux qui savent où ils ont posé leur parapluie ne sont pas alcooliques." - pgibonne.
    Faites du Prolog, ça vous changera les idées !
    Ma page Prolog
    Mes codes sources commentés

    Mon avatar : La Madeleine à la veilleuse de Georges de La Tour

  14. #14
    Rédacteur
    Avatar de Zavonen
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    1 772
    Détails du profil
    Informations personnelles :
    Âge : 76
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 1 772
    Points : 1 913
    Points
    1 913
    Par défaut
    Capito !
    Le header ne fait qu'une déclaration de type, pas de réservation de mémoire.
    Donc, bien que l'instruction soit la même, dans le header et dans le fichier d'implémentation, dans ma première version les variables globales n'étaient pas crées.
    Le Pb était que le linker me donnait un message farfelu.
    Merci encore Trap_D !!!
    Ce qu'on trouve est plus important que ce qu'on cherche.
    Maths de base pour les nuls (et les autres...)

  15. #15
    Expert éminent sénior
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 627
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 4 627
    Points : 10 548
    Points
    10 548
    Par défaut
    En fait, cela veut dire que c'est un problème subtil (du moins je l'analyse comme cela): le mot clef extern s'utilise avec une notion de module (-> le fichier .h + le fichier .c + les fichiers inclus)

    En mettant tes 2 variables Resolx,Resoly; dans globals.h, tes 2 variables vont être compilées dans le premier module qui l'inclue (on va dire le module first).
    Mais ta procédure void InitGlobals() (qui est dans le module global) utilise des variables qui sont donc dans le module first

    La première fois cela marche parce qu'il compile tout le monde. Alors qu'après, il ne compile pas le module global qui a besoin des 2 variables: elle est peut-être là l'explication

    C'est pour cela qu'en mettant les 2 variables Resolx,Resoly; dans le module global [dans le fichier "global.c"], il suffit de faire un extern dans les autres modules (typiquement dans "global.h" qui est la solution la plus élégante)

  16. #16
    Rédacteur/Modérateur
    Avatar de Trap D
    Profil pro
    Inscrit en
    Septembre 2003
    Messages
    4 942
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2003
    Messages : 4 942
    Points : 6 498
    Points
    6 498
    Par défaut
    Ouaih. Le fait que ça ait marché une fois est assez inquiétant pour le compilo. A mon avis, il y a peut être eu entre temps une "petite" modif (par exemple l'inclusion du .h dans un deuxième fichier .c) qui a fait apparaître le problème.
    "La haine seule fait des choix" - Koan Zen
    "Il ne faut pas être meilleur que les autres, il faut être meilleur que soi." Albert Jacquard
    "Ceux qui savent où ils ont posé leur parapluie ne sont pas alcooliques." - pgibonne.
    Faites du Prolog, ça vous changera les idées !
    Ma page Prolog
    Mes codes sources commentés

    Mon avatar : La Madeleine à la veilleuse de Georges de La Tour

  17. #17
    Rédacteur
    Avatar de Zavonen
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    1 772
    Détails du profil
    Informations personnelles :
    Âge : 76
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 1 772
    Points : 1 913
    Points
    1 913
    Par défaut
    Citation Envoyé par Trap D Voir le message
    Ouaih. Le fait que ça ait marché une fois est assez inquiétant pour le compilo. A mon avis, il y a peut être eu entre temps une "petite" modif (par exemple l'inclusion du .h dans un deuxième fichier .c) qui a fait apparaître le problème.
    C'est bien aussi ce qui m'a dérouté.
    Ce qu'on trouve est plus important que ce qu'on cherche.
    Maths de base pour les nuls (et les autres...)

  18. #18
    Rédacteur
    Avatar de Zavonen
    Profil pro
    Inscrit en
    Novembre 2006
    Messages
    1 772
    Détails du profil
    Informations personnelles :
    Âge : 76
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 1 772
    Points : 1 913
    Points
    1 913
    Par défaut
    Citation Envoyé par foetus Voir le message
    En mettant tes 2 variables Resolx,Resoly; dans globals.h, tes 2 variables vont être compilées dans le premier module qui l'inclue (on va dire le module first).
    En fait les variables ne sont pas compilées, en ce sens qu'aucun emplacement mémoire ne leur est réservé correspondant aux types indiqués.
    De facto, ce ne sont que des déclarations de types. Il en aurait été tout autrement si, comme le fait remarquer Trap_D il y avait eu initialisation.
    Bref, dans un fichier d'en-têtes les variables sont annoncées typées mais non déclarées, ce qui permet la compilation correcte des modules appelant le fichier d'en-tête. Mais au moment du linkage, c'est l'éditeur de liens qui associe les symboles déclarés extern dans le header, avec les variables de mêmes noms déclarées dans les fichiers d'implémentation.
    Les directives protègent effectivement de la multi-définition. Tout roule maintenant, et il faut rendre justice à Code::blocks et à Geany. Les IDE n'y sont pour rien. Les choses seraient peut-être plus claires si on avait un mot-clef 'prototype', qui bien qu'alourdissant le code aurait rendu les choses plus claires.
    Trap_D m'a ouvert les yeux en me signalant que globals.c était l'endroit rêvé pour mettre ses variables globales. Il avait bien évidemment raison.
    Merci à tous pour le temps passé et votre serviabilité.
    Ce qu'on trouve est plus important que ce qu'on cherche.
    Maths de base pour les nuls (et les autres...)

  19. #19
    Expert éminent sénior
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 627
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 4 627
    Points : 10 548
    Points
    10 548
    Par défaut
    Ou alors tu as raison , les 2 variables sont déclarées dans "global.h" mais définies dans "global.c"

    Et donc lors des compilations (sauf la première), cette définition n'est pas vue parce qu'elle n'est pas globale, mais locale à la procédure void InitGlobals();.

    Tant bien même, même si on travaille en C, on peut écrire du code propre en évitant ces déclarations/ définitions ambiguës et ces déclarations/ définitions sauvages dans les fichiers headers (on a des structs ou des #define/ enum anonyme)

  20. #20
    Rédacteur/Modérateur
    Avatar de Trap D
    Profil pro
    Inscrit en
    Septembre 2003
    Messages
    4 942
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2003
    Messages : 4 942
    Points : 6 498
    Points
    6 498
    Par défaut
    Citation Envoyé par foetus Voir le message
    Tant bien même, même si on travaille en C, on peut écrire du code propre en évitant ces déclarations/ définitions ambiguës et ces déclarations/ définitions sauvages dans les fichiers headers (on a des structs ou des #define/ enum anonyme)
    Si on a besoin de variables globales (si ! bien entendu) alors il me parait au contraire très propre de les définir dans un seul fichier bien identifié et non pas n'importe où au fur et à mesure des besoins.
    "La haine seule fait des choix" - Koan Zen
    "Il ne faut pas être meilleur que les autres, il faut être meilleur que soi." Albert Jacquard
    "Ceux qui savent où ils ont posé leur parapluie ne sont pas alcooliques." - pgibonne.
    Faites du Prolog, ça vous changera les idées !
    Ma page Prolog
    Mes codes sources commentés

    Mon avatar : La Madeleine à la veilleuse de Georges de La Tour

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. Réponses: 9
    Dernier message: 08/07/2009, 18h10
  2. Comment appeler une fonction externe avec XPath
    Par ttttnht dans le forum XSL/XSLT/XPATH
    Réponses: 1
    Dernier message: 19/06/2009, 14h54
  3. [Boost.Function] Appeler une fonction "externe"
    Par poukill dans le forum Boost
    Réponses: 17
    Dernier message: 29/08/2007, 17h04
  4. Réponses: 12
    Dernier message: 12/05/2006, 10h21
  5. [PHP][Javascript] PB avec appel de fonctions externes, HELP!
    Par chaser_T dans le forum Général JavaScript
    Réponses: 3
    Dernier message: 11/04/2006, 17h44

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo