Il est bien connu mauvaise pratique d'avoir un fichier "super-en-tête" comme "globals.h" ou "includes.h" etc, car en plus des globaux sont mauvais dans le En premier lieu, cela crée également une dépendance de couplage étroit entre chaque fichier unique et non lié de votre projet.

Disons que vous avez un pilote PWM et un module d'impression de débogage RS-232. Vous souhaitez récupérer le module d'impression de débogage RS-232 et le réutiliser dans un autre projet. Soudain, vous avez besoin de PWM.h dont vous n'avez aucune idée de ce que c'est ou d'où vient le besoin. Vous vous surprendrez à vous demander pourquoi diable vous avez besoin d'un pilote PWM pour exécuter RS-232.

Et puis nous n'avons même pas envisagé de rentrer dans cette structure globale désordonnée. Ne faisons même pas ça.

La bonne façon de démêler les spaghettis mondiaux serait plutôt quelque chose comme ceci:

• La variable est-elle utilisée en premier lieu? Sinon, supprimez. (C'est assez courant)
• La variable peut-elle être déplacée vers la portée locale à l'intérieur d'une fonction?
• La variable peut-elle être déplacée vers la portée du fichier .c local en la rendant statique ? Pouvez-vous en réduire l'accès depuis l'extérieur du fichier .c en implémentant des fonctions setter / getter?

Si tout ce qui précède a échoué, alors la variable que vous vous trouvez en train de regarder devrait être soit un registre matériel mappé en mémoire dans une carte de registre, soit un correctif critique en temps réel qui a été ajouté pendant la maintenance.

Cela fonctionnerait pour définir une structure que vous instanciez en tant que variable globale unique.Les accès sur le formulaire «the_global.the_var» n'ajouteront pas de surcharge d'exécution et peuvent clarifier qu'il s'agit bien d'un global. Comme le mentionne https://stackoverflow.com/questions/2868651/including-c-header-file-with-lots-of-global-variables, cela vous évite des déclarations et définitions séparées.

Personnellement, je ne prendrais pas la peine de créer une structure, préférant plutôt trier les globaux dans les fichiers d'en-tête où je pense qu'ils appartiennent logiquement et utiliser un préfixe commun pour chaque fichier d'en-tête.Exemple: fichier Calculate.h déclarant "extern int calc_result;"et calculer.c définissant "int calc_result;"

D'autres variables s'en sortent en étant localement dans un fichier, c'est-à-dire "résultat int statique;"dans le fichier .c.

Puisque vous avez du code hérité avec lequel je suppose que vous ne travaillerez pas beaucoup au-delà du rangement, je dirais que la solution la plus rapide qui crée une structure claire est la meilleure.

Si vous ne pouvez pas vous débarrasser des globaux, je dirais que vous ne devriez les regrouper dans une structure que s'ils sont réellement liés.Sinon, je les garderais séparés ou dans des structures plus petites.

De plus, je n'aimerais pas non plus un fichier globals.h.Gardez-les en haut du fichier source là où ils appartiennent le plus.De cette façon, lorsque vous naviguez dans le code, vous restez probablement à l'endroit où vous étiez ou allez à l'endroit où vous vouliez probablement aller.

En fait, ce n'est pas mieux, le seul avantage est que vous «savez» ce qui est global. Vous avez donc tous les globaux au même endroit, mais ils sont toujours dispersés.

C

Pour chaque global:

• Recherchez le fichier initial dans lequel il est créé ou utilisé.
• Rendez-le statique dans ce fichier
• Si le global est utilisé à de nombreux endroits, utilisez-le en externe à partir d'autres fichiers (en utilisant le mot-clé extern ).
• Mais le moyen préférable est de transmettre la variable aux endroits où elle est nécessaire.

C ++

Pour chaque global:

• Trouvez l'endroit initial où il est créé ou utilisé.
• Trouvez la classe qui convient le mieux.
• Déplacez-le dans cette classe (en tant que champ, connecté à un objet).
• Créez maintenant une méthode Get / Set (fonctions). De préférence, la méthode Set est protégée ou privée).
• Au lieu des méthodes Get et Set, vous pouvez également les transmettre via des arguments de méthode.
• Utilisez les méthodes Get / Set d'autres classes.
• Dans certains cas, vous verrez qu'il ne peut pas être un champ d'une classe, par exemple quand il ne peut y en avoir qu'un. Dans ce cas, utilisez le modèle de conception Singleton. (Méfiez-vous de cela; c'est toujours une sorte de mondial, alors assurez-vous qu'à l'avenir vous n'en ferez plus jamais plus; sinon, c'est un espace global déguisé).

Les grands avantages à placer des variables globales dans une structure sont:

1. C'est clair lorsque vous utilisez une variable globale ou locale.
2. Il est impossible de masquer par accident une variable globale avec une variable locale du même nom.

Les avantages moindres sont:

1. Il est plus facile de déboguer les débogages dans un tableau global ou une mémoire tampon car la disposition de la mémoire peut être déduite de la structure.
2. La structure globale peut être très simplement enregistrée dans / chargée depuis un stockage non volatile.

Une utilisation sensée des variables globales peut réduire les exigences de la pile, mais augmente le risque d'erreur si leur utilisation n'est pas bien documentée et les règles respectées.

Pourquoi y aurait-il un autre niveau d'indirection d'accès aux variables dans une struct ? Si vous déclarez votre structure comme ceci:

  typedef struct tagUART {
    int field1;
    int field2;
} UART;
 

Ensuite, déclarez un global:

  UART uart;
 

Au lieu de déclarer ces globaux:

  int uartField1;
int uartField2;
 

Le compilateur, aussi merdique qu'il puisse être, n'a aucune excuse pour introduire un autre niveau d'indirection si vous accédez à votre variable via uart.field1 qu'avec un accès à uartField1 . Le compilateur connaît l'adresse de départ de votre structure et la déclaration struct définit le décalage de champ dans la structure. Le compilateur sait tout au point de référence.

Maintenant, le niveau supplémentaire d'indirection se produirait si vous commencez à passer des pointeurs vers uart comme arguments de fonction, et les appels de fonction ne sont pas incorporés. Là, le compilateur perd le fait que "Hé, les champs ont une adresse bien connue".

Je sais qu'il existe théoriquement un autre niveau d'indirection lors de leur accès,

Ça dépend, un compilateur vraiment stupide peut introduire des niveaux supplémentaires d'indirection pour une structure, mais un compilateur intelligent peut en fait produire un meilleur code si une structure est impliquée.

Contrairement à d'autres réponses, le compilateur NE connaît PAS l'adresse des variables globales. Pour les variables globales dans la même unité de compilation, il connaît leur emplacement les uns par rapport aux autres, mais pas leur emplacement absolu. Pour les variables d'autres unités de compilation, il ne sait rien de leur emplacement en termes absolus ou relatifs.

Au lieu de cela, le code généré par le compilateur aura des espaces réservés pour les emplacements des variables globales, ceux-ci seront ensuite remplacés par des emplacements réels lorsque l'adresse finale est déterminée (traditionnellement lorsque le programme est lié, mais parfois pas avant son exécution ).

De plus, bien que certains processeurs (comme le 6502) puissent accéder directement à un emplacement mémoire global sans aucune configuration préalable, il y en a beaucoup qui ne le peuvent pas. Sur arm par exemple, pour accéder à une variable globale, le compilateur doit d'abord charger l'adresse de la variable dans un registre, soit en utilisant un pool littéral, soit, sur les versions plus récentes d'arm, en utilisant movw / movt. Accédez ensuite à la variable globale en utilisant une instruction de chargement relative au registre.

Cela signifie que pour les variables en dehors de l'unité de compilation, l'accès à plusieurs éléments de la même structure globale est probablement plus efficace que l'accès à des variables globales individuelles.

Pour tester cela, j'ai introduit le code suivant dans godbolt avec l'optimisation ARM gcc 8.2 et -O3.

  extern int a;
extern int b;

struct Foo {
    int a;
    int b;
};

extern struct Foo foo;

void f1 (void) {
    a = 1;
    b = 2;
}

void f2 (void) {
    toto.a = 1;
    toto.b = 2;
}
 

Cela a abouti à

  f1:
        mov r0, # 1
        mov r2, # 2
        ldr r1, .L3
        ldr r3, .L3 + 4
str r0, [r1]
        str r2, [r3]
        bx lr
.L3:
        .word a
        .word b
f2:
        mov r1, # 1
        mov r2, # 2
        ldr r3, .L6
        stm r3, {r1, r2}
        bx lr
.L6:
        .word foo
 

Dans le cas de f1, nous voyons que le compilateur charge les adresses de a et b séparément des pools littéraux (les adresses dans les pools littéraux seront remplies plus tard par l'éditeur de liens).

Cependant dans le cas de f2 le compilateur n'a qu'à charger l'adresse de la structure du pool littéral une seule fois, mieux encore car il sait que les deux variables sont côte à côte en mémoire il peut les écrire avec un seul "storeplusieurs "instructions plutôt que deux instructions de magasin séparées.

mais à partir d'un style de POV, est-ce mieux ou pire que de les mettre dans des fichiers globals.c et / ou globals.h?

IMO qui dépend si les variables sont réellement liées ou non.