Discussion :

[Bktero]

C'est justement une mauvaise idée de les regrouper. Ca tue la modularité car cela lie plus fortement les modules entre eux et limite la ré-utilisabilité de ces modules. On en a parlé sur Developpez il y a peu.

[Zavonen]

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.

Oui, on évite déjà les ainsi conflits de noms. Il ne restera plus que les problèmes de masquage par des variables locales qui ne sont pas à sous-estimer. Les théoriciens de la prog. sont par principe contre les variables globales, mais en pratique cela simplifie la vie. Ne pas avoir accès instantanément aux dimensions de l'écran quand on programme un jeu vidéo, c'est frustrant. Même en C++ authentique passer par les Truc.Getx .... c'est gonflant. Ce n'est qu'une opinion valable pour un programme modeste conçu par une seule personne. Maintenant, pour le travail collaboratif, peut-être est-il plus payant de respecter toutes les règles.

Ca tue la modularité car cela lie plus fortement les modules entre eux et limite la ré-utilisabilité de ces modules. On en a parlé sur Developpez il y a peu.

Dans le programme que je suis en train de développer seuls les fichiers main.c et global.c feront apparaître une inclusion vers gobals.h, et ce n'est pas un hasard. C'est un programme C, sans classes, mais respectant les règles de la P.O.O. tous les objets susceptibles d'avoir une certaine universalité (réutilisabilité) sont définis par un header et un fichier d'implémentation. Les fonctions d'initialisation, jouant le rôle de constructeurs, sont définis au moyen de paramètres. Les initialisations véritables se font dans globals.c au moyen d'appels de ces fonctions en passant en paramètres les variables globales définies dans le même fichier.
On peut faire des choses propres sans être dogmatique.

[foetus]

Et une dernière chose: tes conventions de codage ("coding style") sont mauvaises

Pour des variables globales qui vont être, en théorie, utilisées un peu partout il faut les différencier: soit tout en majuscule soit en les préfixant par exemple avec "g_"
Les fonctions globales elles peuvent subir le même sort:
À réfléchir parce que les fonctions définie avec un #define sont en pratique déjà toutes en majuscule.

[Invité]

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...

Si cette discussion n'a pas encore été résolue, je dirais que le problème vient des inclusions.

Remarque : Le fichier global.c ne sera pas inclus dans le fichier principal car tu ne l'as pas inclus dans le fichier global.h. De même tu ne l'as pas inclus dans le fichier principal, or tu as inclus dans le fichier principal le fichier global.h qui affirme l'existence d'une fonction nommée InitGlobals().
Sauf que tu as déclaré la fonction InitGloabl() dans le fichier global.c, c'est-à-dire que tout son code est dans le fichier global.c. Ceci explique le message du compilateur au sujet de InitGlobals.

Pour mieux comprendre, dis-toi ou rappelle-toi qu'un #include <mon_fichier> équivaut à copier tout le contenu de mon_fichier dans le fichier dans lequel tu as écrit la macro (#include) et à ce même emplacement. Si tu appliques cette vision des choses, tu verras que le fichier globals.c et donc tout son contenu n'est pas inclus dans le fichier principal et donc tout son contenu sera absent.

Conseille (proposition 1 ou 2):

1- Enlève le #include "globals.h" dans le fichier globals.c et écris #include "globals.c" dans le fichier globals.h (à la fin du fichier) et recompile le tout.

2- Remplace le #include "globals.h" dans le fichier principal par un #include "globals.c", ça devrait marcher.

Remarque:

J'ai bâtit cette réponse à partir de mon expérience avec l'IDE TIGCC.

[foetus]

Si cette discution n'a pas encore était résolu, je dirais que le problème viens des inclusions.

Non cela dépend si le compilateur voit cela comme une déclaration ou une définition et aussi de la politique "extern" par défaut du compilateur des variables.

Et aussi , faire une initialisation paresseuse des variables globales assez douteuse et exposer à la fois les fonctions et les variables globales (avec des conventions de codage mauvaises)