Y compris C fichier d'en-tête avec beaucoup de variables globales

J'ai un fichier inclus avec+ de 100 variables globales. Il est utilisé dans une bibliothèque, mais certains programmes que je suis reliant la lib également besoin d'accéder à la globals.

La façon dont il a été construit:

//In one library .c file
#define Extern

//In the programs that use the globals
#define Extern extern

//In the .h file
Extern int a,b,c;

J'ai eu du mal à comprendre pourquoi l'original programmeur a fait que j'ai donc enlevé qui définissent Extern choses. Maintenant, je pense que je comprends la chose à propos de TU avec l'aide de stackoverflow:
Un,
Deux,
Trois.

Maintenant, je comprends que je dois définir les variables globales dans un .c fichier dans la bibliothèque et de l'utilisation extern dans l' .h fichier. Le problème est que je ne veux pas dupliquer le code.

Dois-je retourner à #define Extern vaudou?

Désolé de venir ces derniers temps mais le a accepté de répondre est la mauvaise approche. Frederik Slijkerman réponse est la bonne. Seules les déclarations dans .h les fichiers et les définitions .c fichiers. extern var est une déclaration, sans extern il s'agit d'une définition. Mettre la définition de la variable dans le module (c'est à dire .fichier c) est-il logique (du point de vue sémantique) de la partie de. À l'inverse, ne jamais utiliser un extern var dans un .c fichier.

InformationsquelleAutor Costi | 2010-05-19

c gcc

8

L'astuce ici est que l' .h fichier est utilisé de deux façons différentes - il est utilisé comme normal .h fichier dans lequel toutes les variables globales sont déclarées extern et il est également utilisé pour définir la globals eux-mêmes (sans extern). C'est un vilain hack mais vous pouvez comprendre pourquoi quelqu'un a estimé nécessaire si vous avez un grand nombre de variables globales (un signe sûr de très mauvaise conception de logiciel !).

De toute façon, il y a un peu plus de solution élégante - vous pouvez mettre tous vos globales dans un seul struct global, par exemple
```
//
//globals.h
//

typedef struct {
    int a;
    int b;
    //...
    int z;
} Globals;

extern Globals globals; //declaration
```
-
```
//
//globals.c
//

#include "globals.h"

Globals globals; //definition
```
-

Puis, quand vous avez besoin de se référer à un mondial, c'est par exemple globals.a au lieu de simplement a, ce qui peut sembler être un inconvénient, mais c'est sans doute plus claire et plus facile à gérer que d'avoir nu globals dispersés dans tout le code.
- Est certainement 🙂
- Vous avez raison, et de mettre ces variables globales dans certaines structures est un TODO. Il est même possible de leur donner des noms.
InformationsquelleAutor Paul R
6

C'est un mauvais modèle pour définir Extern dans tous les .c fichier. Retrait il est probablement le meilleur, mais vous avez besoin de remplacer cette fonctionnalité en quelque sorte. Une approche est que vous pouvez utiliser un #define dans le .c fichier qui doit définir ces variables globales. Ce sera le signal de définir à l' .h pour ne extern les variables globales.

Par exemple:
Une bibliothèque .fichier c:
```
#define FOO_LIBRARY_C
#include "foo_library.h"
```
L'autre .c fichiers:
```
#include "foo_library.h"
```
foo_library.h:
```
#ifdef FOO_LIBRARY_C
int a,b,c
#else
extern int a,b,c
#endif
```
ou
```
#ifdef FOO_LIBRARY_C
#define GLOBAL_PREFIX
#else 
#define GLOBAL_PREFIX extern
#endif

GLOBAL_PREFIX int a,b,c
```
Cela réduit la nécessité de définir la même chose dans chaque fichier source (sauf un) et contribuerait à réduire les erreurs. Je n'ai pas l'appeler Extern que peuvent causer de la confusion, comme il peut ou ne peut pas être "extern"
- Je suis en désaccord que c'est un mauvais motif:je sais que cela va à l'encontre de la perception de la sagesse d'avoir l'externes dans .h les fichiers, mais pour ce cas, je ne vois pas d'autres inconvénients que d'avoir à écrire un peu plus extern définitions. Si vous trouvez la nécessité d'écrire des tonnes d'entre eux, votre code est un gâchis (beaucoup trop de variables globales) et vous devriez en tout cas TOUJOURS penser à comment et où les utiliser, car ils peuvent provoquer de très bogues subtils. À l'aide d'un .h fichier que vous êtes en vous donnant une carte blanche pour utiliser des variables globales indisriminantly.
- Des Makis, vous êtes l'amalgame entre 2 choses ici; - le choix de conception de l'utilisation de variables globales et de la meilleure pratique lorsque vous devez utiliser une variable globale. Il est clair que l'utilisation de variables globales est généralement une mauvaise idée, mais quand vous avez à utiliser, utilisez le meilleur usage de sa mise en œuvre et qui est extern var déclaration dans l'en-tête et var définition dans le droit .c fichier. Tout autre type d'utilisation est incorrecte.
InformationsquelleAutor Aaron
3

Peut-être que je suis absent quelque chose de trop, mais je TOUJOURS utilisation de l'inclusion des gardes sur tous les fichiers d'en-tête j'ai créer:

foo.h:
```
#ifndef FOO_H
#define FOO_H

extern int foo;

#endif
```
foo.c:
```
#include "foo.h"

int foo = 0;
```
bar.c:
```
#include "foo.h"
#include <stdio.h>
int main(int argc, char** argv)
{
    printf("foo:%d\n",foo);
    return 0;
}
```
- Je pense que cette stratégie simple de ne pas travailler avec les bibliothèques et les programmes comprennent le même fichier d'en-tête.
- Je préfère de beaucoup de ce sur Aaron méthode également répertorié ici. Avoir les définitions dans un fichier et les déclarations dans un autre plus de sens pour moi, et semble être un beaucoup plus sur le modèle commun.
- Les gens, cela ne fonctionne pas. Imaginez si je compile à la bibliothèque, et, à une date ultérieure, compiler un programme qui comprend que .h fichier. Tous deux auront la globals SANS extern. C'est la situation que je vais décrire.
- foo.c est la partie de la bibliothèque, à cet effet, les variables globales sont dans la bibliothèque. les programmes comprennent toutes foo.h - où les variables globales sont définies extern. l'inclusion des gardes permettra à chacun séparément construit son programme de foo.h la fois. pouvez-vous expliquer comment cela est rompu parce que je ne le vois pas.
- Mon mauvais les gars. Je vois maintenant que foo.c "int foo=0". Mais je vois toujours un problème avec cette approche: j'ai plus de 100 variables globales et c'est beaucoup de code dupliqué dans le .c et .h lib fichiers . Avec Aaron solution, ils seront déclarés que dans le .h fichier.
- Vrai, je suppose. À partir de quelques recherches rapides pour la "bibliothèque c avec des variables globales" j'ai l'impression que le fait d'avoir globales dans une bibliothèque est une mauvaise idée de toute façon. Si j'ai lu correctement, si les deux simultanément les programmes en cours d'exécution partagent le même ensemble de variables globales ou ont leurs propres copies, ne saurait être invoqué et est spécifique au système d'exploitation, etc.
- Je ne pense pas que les données sont partagées entre les processus en cours d'exécution à l'aide de la même bibliothèque. Et, de toute façon nous sommes lier statiquement à notre propre lib 🙂
- Si ce n'est pas votre bibliothèque, il n'est pas question de savoir si les codes sont dupliqués. Si c'est votre bibliothèque, vous devriez vraiment éviter l'utilisation de ces nombreuses variables globales. Même Paul R solution est beaucoup mieux. James Morris donne le plus de solution standard.
- +1. Vous ne devriez pas être à l'aide de l'inclusion des fichiers d'en-tête à inclure "code" (par opposition à des définitions). Je sais que la ligne est floue ici, mais l'idée d'appuyer sur le mot-clé extern off pour effectivement avoir l'en-tête de la fonction, comme la définition des œuvres, mais est juste un sous-produit de la gestion de "trop" globales " de toute façon (je sais c'est subjectif, mais je suis en expliquant pourquoi ce modèle n'est pas si commun dans la nature.)
InformationsquelleAutor James Morris
3

La macro choses est stupide pour cela. Vient de mettre
```
extern int myGlobal;
```
dans votre fichier d'en-tête, et, dans UN .c fichier (généralement un avec le même nom que le .h fichier), mettre
```
int myGlobal;
```
Pas besoin de se stresser à propos de ce niveau de "duplication".
- Ce doit être la accepté de répondre. C'est le seul sain d'esprit de l'approche. Toute autre préprocesseur acrobatique présentée dans les autres réponses sont fausses, l'ajout de bruit inutile dans le code.
InformationsquelleAutor Frederik Slijkerman
2

J'ai peut-être raté quelque chose, mais je ne vois pas de différence entre les #define truc et simplement à l'aide de la extern mot-clé.

Fondamentalement, vous devez déclarer le var dans une .h fichier et de le définir dans une .c fichier. Ne la considèrent pas la duplication de code - je pense que changer le point de vue est la meilleure chose que vous pouvez faire ici :). Vous pouvez écrire plusieurs lignes de code, mais ils vont être lisible :D.
- Je suis prêt à être que EXTERN est placé dans la déclaration et les fichiers d'en-tête pour faire des couper-coller de la valeur juste que beaucoup plus facile à utiliser et d'avoir un visuel que cela dit de la var est de portée mondiale sont visibles. Cela dit, je frémis sur le merveilleux abus cela permet partout. Oh les jours de spaghetti var suivi...
- Eh bien, je le fais pour dll_export et, mais c'est parce que M$de capital de risque et de gcc ne Dll différemment. Comme pour les externes, je préfère en avoir un .h et un .fichier c pour eux. Comme je l'ai dit, c'est plus de code, mais j'aime la lisibilité. Peut-être que c'est juste une question de préférence personnelle, je ne sais pas. Puis de nouveau, si je erite illisible code, je voudrais apprendre à programmer en Brainf*ck ou quelque chose de similaire 🙂
- Ce est la raison pour laquelle je ne spécifiez global des noms de variables en quelque sorte, même si je déteste la notation hongroise avec une vengeance. Selon le style de ce programme, j'utilise soit le "g" ou "g_" préfixe pour ces. Il permet à des inspections plus qu'on ne pourrait le croire.
- +1 je seconde que je vais encore plus loin. Ne jamais définir une variable globale dans un en-tête, jamais, ne fait pas exception, il n'apporte que souffrance et de chagrin. Inclure les fichiers doivent être idempotent.
InformationsquelleAutor mingos
1

Dans de grands programmes, il est très important d'avoir une seule ligne de déclarer et définir une variable globale. Par conséquent, la macro approche décrite ci-dessus est la bonne façon d'aborder la question.
```
//globals.h 
#ifndef GLOBALS_H 
#define GLOBALS_H  
#ifndef EXTERN 
#define EXTERN extern 
#endif
EXTERN int i; 
#endif  

//globals.c 
#define EXTERN 
#include "globals.h" 
```
InformationsquelleAutor user784723
0

Comme une règle du pouce - ne pas utiliser de variables globales. Parfois, vous avez besoin d'utiliser des variables dans le fichier mais il est préférable d'essayer de les éviter à tout:
- Vous ne pouvez pas l'unité de tester correctement le code qui contient les variables globales
- Il n'y a pas de séparation nette entre des modules, qui peuvent causer des problèmes avec l'isolement des erreurs
- Il est généralement pas thread-safe. Vous avez de l'envelopper avec les mutex etc. si vous souhaitez utiliser des threads (tend à être meilleure et la meilleure idée que nous avons de plus en plus de cœurs) vous pouvez avoir des problèmes avec les droits en écriture partagée de l'état.
Parfois en C, vous ne pouvez les éviter (en particulier dans le code hérité de quelqu'un) mais il est préférable de les garder hors.

Comme pour la déclaration, il peut être utile dans ce cas:
```
//globals.h

#ifndef GLOBALS_H
#define GLOBALS_H

#ifndef EXTERN
#define EXTERN extern
#endif

EXTERN int i;
#endif

//globals.c
#define EXTERN
#include "globals.h"
```
InformationsquelleAutor Maciej Piechotka

-1

Alors que cela peut être gênant au début, il ne vous aider à éviter d'avoir à taper chose deux fois ou oublier d'inclure quelque chose dans un .c fichier.
J'ai vu:

#define FOO_C_

#include "foo.h"
#include "bar.h"

int foo_doit(int a, int b, int c) {
...
}

avec toto.h étant:

#ifndef FOO_H_
#define FOO_H_

#ifdef FOO_C_
#define GLOBAL
#define DECLARE( type, name, value) type name = value
#else
#define GLOBAL extern
#define DECLARE( type, name, value) extern type name;
#endif

GLOBAL int foo_doit(int a, int b, int c);
GLOBAL int foo_it; //uninitialized global variable
DECLARE(char, that[], "that");

//and sometimes using:
#ifdef FOO_C_
char word[] = letters;
#else
extern char word[];
#endif


#endif //FOO_H_

À l'échelle MONDIALE sur les déclarations de fonction est inutile. Le point-virgule après la seconde #define DECLARE est erronée.

InformationsquelleAutor nategoose

Vous devez vous connecter pour publier un commentaire.