È ben nota la cattiva pratica di avere un file "super header" come "globals.h" o "includes.h" ecc., perché oltre alle variabili globali sono cattive nel in primo luogo, questo crea anche una stretta dipendenza di accoppiamento tra ogni singolo file non correlato nel progetto.

Supponiamo che tu abbia un driver PWM e un modulo di stampa di debug RS-232. Vuoi prendere il modulo di stampa di debug RS-232 e riutilizzarlo in un altro progetto. All'improvviso ti ritrovi ad aver bisogno di un PWM.h di cui non hai la più pallida idea di cosa sia o da dove venga il bisogno. Ti ritroverai a chiederti perché diavolo hai bisogno di un driver PWM per eseguire RS-232.

E poi non abbiamo nemmeno considerato il rientro di questa struttura globale disordinata. Non lo facciamo nemmeno.

Il modo corretto per districare gli spaghetti globali sarebbe piuttosto qualcosa del genere:

• La variabile viene utilizzata in primo luogo? In caso contrario, rimuovere. (Questo è abbastanza comune)
• La variabile può essere spostata in ambito locale all'interno di una funzione?
• È possibile spostare la variabile nell'ambito del file .c locale rendendola statica ? Puoi ridurre l'accesso dall'esterno del file .c implementando le funzioni setter / getter?

Se tutto quanto sopra non è riuscito, la variabile che ti trovi a guardare dovrebbe essere una parte del registro hardware mappata in memoria di una mappa di registro, oppure è una correzione sporca critica in tempo reale che è stata aggiunta durante la manutenzione.

Funzionerebbe per definire una struttura di cui istanziare come singola variabile globale.Gli accessi nella forma "the_global.the_var" non aggiungeranno un sovraccarico di runtime e possono chiarire che è effettivamente globale. Come menzionato https://stackoverflow.com/questions/2868651/including-c-header-file-with-lots-of-global-variables, ti salva da dichiarazioni e definizioni separate.

Personalmente non mi preoccuperei di creare una struttura, preferendo invece ordinare le globali nei file di intestazione a cui sento che logicamente appartengono e utilizzare un prefisso comune per ogni file di intestazione.Esempio: file calcola.h che dichiara "extern int calc_result;"e calcola.c definendo "int calc_result;"

Altre variabili se la cavano con l'essere file locali, ad esempio "static int result;"nel file .c.

Dato che hai un codice legacy con cui immagino che non lavorerai molto oltre a metterlo in ordine, direi che la soluzione più rapida che consente una struttura chiara è la migliore.

Se non puoi sbarazzarti delle variabili globali, direi che dovresti comprimerle insieme in una struttura solo se sono effettivamente correlate.In caso contrario, li terrei separati o in strutture più piccole.

Inoltre, non vorrei nemmeno un file globals.h.Tienili in cima al file sorgente a cui appartengono maggiormente.In questo modo, quando navighi nel codice, probabilmente rimani nel luogo in cui ti trovavi o vai nel luogo in cui probabilmente volevi andare.

In realtà, non è meglio, l'unico vantaggio è che "sai" quali sono globali. Quindi hai tutte le globali in un unico posto, ma sono ancora sparse.

C

Per ogni globale:

• Trova il file iniziale in cui è stato creato o utilizzato.
• Rendilo statico in quel file
• Nel caso in cui il global venga utilizzato in molti posti, usalo esternamente da altri file (utilizzando la parola chiave extern ).
• Ma il modo preferibile è passare la variabile nei punti in cui è necessaria.

C ++

Per ogni globale:

• Trova la posizione iniziale in cui viene creato o utilizzato.
• Trova la classe a cui si adatta meglio.
• Spostalo in quella classe (come campo, connesso a un oggetto).
• Ora crea un metodo Get / Set (funzioni). Preferibilmente il metodo Set è protetto o privato).
• Invece dei metodi Get e Set, puoi anche passarli attraverso gli argomenti del metodo.
• Utilizza i metodi Get / Set di altre classi.
• In alcuni casi vedrai che non può essere un campo di una classe, ad esempio quando può essercene solo "uno". In questo caso, usa il design pattern Singleton. (Attenzione a questo; è ancora una specie di globale, quindi assicurati di non farne mai più in futuro; altrimenti è uno spazio globale sotto mentite spoglie).

I grandi vantaggi dell'inserimento di variabili globali in una struttura sono:

1. È chiaro quando utilizzi una variabile globale rispetto a una variabile locale.
2. È impossibile mascherare accidentalmente una variabile globale con una variabile locale con lo stesso nome.

I vantaggi minori sono:

1. È più facile eseguire il debug degli overflow in un array globale o in un buffer di memoria perché il layout della memoria può essere dedotto dalla struttura.
2. La struttura globale può essere molto semplicemente salvata / caricata da una memoria non volatile.

Un uso ragionevole delle variabili globali può ridurre i requisiti di stack, ma aumenta il rischio di errore se il loro utilizzo non è ben documentato e le regole rispettate.

Perché dovrebbe esserci un altro livello di accesso indiretto alle variabili in una struct ? Se dichiari la tua struttura in questo modo:

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

Quindi dichiara un globale:

  UART uart;
 

Invece di dichiarare questi valori globali:

  int uartField1;
int uartField2;
 

Il compilatore, per quanto schifoso possa essere, non ha scuse per introdurre un altro livello di riferimento indiretto se accedi alla tua variabile tramite uart.field1 rispetto a quello che farebbe con un accesso a uartField1 . Il compilatore conosce l'indirizzo iniziale della vostra struttura e la dichiarazione della struttura definisce l'offset del campo all'interno della struttura. Il compilatore sa tutto nel punto di riferimento.

Ora, il livello extra di riferimento indiretto si verifica se inizi a passare i puntatori a uart come argomenti di funzione e le chiamate di funzione non vengono inline. Lì, il compilatore perde il fatto che "Ehi, i campi hanno un indirizzo ben noto".

So che teoricamente esiste un altro livello di riferimento indiretto quando si accede ad essi,

Beh, dipende, un compilatore veramente stupido può introdurre livelli extra di riferimento indiretto per una struttura, ma un compilatore intelligente può effettivamente produrre codice migliore se è coinvolta una struttura.

Contrariamente ad altre risposte, il compilatore NON conosce l'indirizzo delle variabili globali. Per le variabili globali nella stessa unità di compilazione conosce la loro posizione l'una rispetto all'altra, ma non la loro posizione assoluta. Per le variabili in altre unità di compilazione non sa nulla della loro posizione in termini assoluti o relativi.

Invece il codice generato dal compilatore avrà dei segnaposto per le posizioni delle variabili globali, queste saranno poi sostituite dalle posizioni effettive quando viene determinato l'indirizzo finale (tradizionalmente quando il programma è collegato, ma a volte non finché non viene eseguito ).

Inoltre, mentre ci sono alcune CPU (come il 6502) che possono accedere direttamente a una posizione di memoria globale senza alcuna configurazione precedente, ce ne sono molte che non possono. Ad esempio, su arm, per accedere a una variabile globale, il compilatore deve in genere caricare prima l'indirizzo della variabile in un registro, utilizzando un pool letterale o, nelle versioni più recenti di arm, utilizzando movw / movt. Quindi accedi alla variabile globale utilizzando un'istruzione di caricamento relativa al registro.

Ciò significa che per variabili esterne all'unità di compilazione l'accesso a più elementi della stessa struttura globale è probabilmente più efficiente rispetto all'accesso a singole variabili globali.

Per testarlo ho inserito il seguente codice in godbolt con ARM gcc 8.2 e ottimizzazione -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) {
    foo.a = 1;
    foo.b = 2;
}
 

Questo ha portato a

  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
 

Nel caso di f1 vediamo che il compilatore carica gli indirizzi di aeb separatamente dai pool letterali (gli indirizzi nei pool letterali verranno inseriti successivamente dal linker).

Tuttavia nel caso di f2 il compilatore deve caricare solo una volta l'indirizzo della struttura dal pool letterale, meglio ancora perché sa che le due variabili sono una accanto all'altra in memoria può scriverle con un unico "archiviopiù "istruzioni" anziché due istruzioni separate per il negozio.

ma da uno stile POV è meglio o peggio che metterli nei file globals.c e / o globals.h?

IMO che dipende se le variabili sono effettivamente correlate o meno.