Es ist bekannt, dass schlechte Praxis eine "Super-Header" -Datei wie "globals.h" oder "include.h" usw. hat, weil zusätzlich zu Globals in der Erstens schafft dies auch eine enge Kopplungsabhängigkeit zwischen jeder einzelnen, nicht verwandten Datei in Ihrem Projekt.

Nehmen wir an, Sie haben einen PWM-Treiber und ein RS-232-Debug-Druckmodul. Sie möchten das RS-232-Debug-Druckmodul herunterladen und in einem anderen Projekt wiederverwenden. Plötzlich brauchen Sie ein PWM.h, von dem Sie keine Ahnung haben, was es ist oder woher das Bedürfnis kommt. Sie werden sich fragen, warum um alles in der Welt Sie einen PWM-Treiber benötigen, um RS-232 auszuführen.

Und dann haben wir noch nicht einmal daran gedacht, diese chaotische globale Struktur wieder aufzunehmen. Lass uns das nicht einmal tun.

Der richtige Weg, um globale Spaghetti zu entwirren, wäre eher so:

• Wird die Variable überhaupt verwendet? Wenn nicht, entfernen Sie. (Dies ist ziemlich häufig)
• Kann die Variable innerhalb einer Funktion in den lokalen Bereich verschoben werden?
• Kann die Variable in den lokalen Dateibereich .c verschoben werden, indem sie statisch gemacht wird? Können Sie den Zugriff von außerhalb der Datei .c reduzieren, indem Sie Setter / Getter-Funktionen implementieren?

Wenn alle oben genannten Fehler aufgetreten sind, sollte die Variable, die Sie sich ansehen, entweder ein speicherabgebildeter Hardwareregisterteil einer Registerzuordnung sein oder es handelt sich um einen kritischen Dirty Fix in Echtzeit, der während der Wartung hinzugefügt wurde.

Es würde funktionieren, eine Struktur zu definieren, die Sie als einzelne globale Variable instanziieren.Zugriffe auf das Formular 'the_global.the_var' erhöhen nicht den Laufzeitaufwand und können klarstellen, dass es sich tatsächlich um einen globalen handelt. Wie https://stackoverflow.com/questions/2868651/including-c-header-file-with-lots-of-global-variables erwähnt, werden Sie vor separaten Deklarationen und Definitionen geschützt.

Persönlich würde ich mir nicht die Mühe machen, eine Struktur zu erstellen, sondern Globale lieber in die Header-Dateien zu sortieren, in denen sie meiner Meinung nach logisch hingehören, und für jede Header-Datei ein gemeinsames Präfix verwenden.Beispiel: Datei berechne.h mit der Angabe "extern int calc_result;"und berechne.c, die "int calc_result" definiert;

Andere Variablen sind nicht lokal, d. h. "static int result".in der .c-Datei.

Da Sie Legacy-Code haben, mit dem Sie vermutlich nicht viel zu tun haben, außer ihn aufzuräumen, würde ich sagen, dass die schnellste Lösung für eine klare Struktur die beste ist.

Wenn Sie die Globals nicht loswerden können, sollten Sie sie nur dann in einer Struktur zusammenfassen, wenn sie tatsächlich verwandt sind.Wenn nicht, würde ich sie getrennt oder in kleineren Strukturen aufbewahren.

Außerdem möchte ich auch keine globals.h-Datei.Bewahren Sie sie oben in der Quelldatei auf, wo sie am meisten hingehören.Auf diese Weise bleiben Sie beim Navigieren durch den Code wahrscheinlich an dem Ort, an dem Sie sich befanden, oder gehen zu dem Ort, an den Sie wahrscheinlich wollten.

Eigentlich ist es nicht besser, der einzige Vorteil ist, dass Sie wissen, welche global sind. Sie haben also alle Globalen an einem Ort, aber sie sind immer noch verstreut.

C

Für jede globale:

• Suchen Sie die ursprüngliche Datei, in der sie erstellt oder verwendet wird.
• Machen Sie es in dieser Datei statisch
• Wenn das Global an vielen Stellen verwendet wird, verwenden Sie es extern aus anderen Dateien (mit dem Schlüsselwort extern ).
• Am besten übergeben Sie die Variable an die Stellen, an denen sie benötigt wird.

C ++

Für jede globale:

• Suchen Sie den ursprünglichen Ort, an dem es erstellt oder verwendet wird.
• Finden Sie die Klasse, zu der es am besten passt.
• Verschieben Sie es in diese Klasse (als Feld, verbunden mit einem Objekt).
• Erstellen Sie nun eine Get / Set-Methode (Funktionen). Vorzugsweise ist die Set-Methode geschützt oder privat.
• Anstelle von Get and Set-Methoden können Sie diese auch über Methodenargumente übergeben.
• Verwenden Sie Get / Set-Methoden aus anderen Klassen.
• In einigen Fällen können Sie feststellen, dass es sich nicht um ein Feld einer Klasse handeln kann, z. B. wenn es nur ein Feld geben kann. Verwenden Sie in diesem Fall das Singleton-Entwurfsmuster. (Passen Sie auf; es ist immer noch eine Art globaler, also stellen Sie sicher, dass Sie in Zukunft nie mehr davon machen werden; andernfalls ist es ein globaler Raum in Verkleidung)

Die großen Vorteile beim Einfügen globaler Variablen in eine Struktur sind:

1. Es ist klar, wenn Sie eine globale oder eine lokale Variable verwenden.
2. Es ist unmöglich, versehentlich eine globale Variable mit einer gleichnamigen lokalen Variablen zu maskieren.
ol>

Kleinere Vorteile sind:

1. Es ist einfacher, Überläufe in einem globalen Array oder Speicherpuffer zu debuggen, da das Speicherlayout aus der Struktur abgeleitet werden kann.
2. Die globale Struktur kann sehr einfach in einem nichtflüchtigen Speicher gespeichert / aus diesem geladen werden.
ol>

Die sinnvolle Verwendung globaler Variablen kann die Stapelanforderungen verringern, erhöht jedoch das Fehlerrisiko, wenn ihre Verwendung nicht gut dokumentiert und die Regeln eingehalten werden.

Warum sollte es in einer -Struktur eine andere Ebene der Indirektion geben, die auf Variablen zugreift? Wenn Sie Ihre Struktur wie folgt deklarieren:

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

Dann deklarieren Sie ein globales:

  UART uart;
 

Anstatt diese Globalen zu deklarieren:

  int uartField1;
int uartField2;
 

Der Compiler, so beschissen er auch sein mag, hat keine Entschuldigung, eine andere Indirektionsebene einzuführen, wenn Sie über uart.field1 auf Ihre Variable zugreifen, als dies bei einem Zugriff auf uartField1 . Der Compiler kennt die Startadresse Ihrer Struktur und die Strukturdeklaration definiert den Feldversatz innerhalb der Struktur. Der Compiler weiß alles am Referenzpunkt.

Jetzt würde die zusätzliche Indirektionsebene eintreten, wenn Sie Zeiger als Funktionsargumente an uart übergeben und die Funktionsaufrufe nicht inline werden. Dort verliert der Compiler die Tatsache, dass "Hey, die Felder haben eine bekannte Adresse".

Ich weiß, dass es theoretisch eine andere Indirektionsebene gibt, wenn auf sie zugegriffen wird,

Nun, es kommt darauf an, dass ein wirklich dummer Compiler zusätzliche Indirektionsebenen für eine Struktur einführt, aber ein intelligenter Compiler kann tatsächlich besseren Code erzeugen, wenn eine Struktur beteiligt ist.

Im Gegensatz zu anderen Antworten kennt der Compiler die Adresse globaler Variablen NICHT. Für globale Variablen in derselben Kompilierungseinheit ist ihre Position relativ zueinander bekannt, nicht jedoch ihre absolute Position. Für Variablen in anderen Kompilierungseinheiten weiß sie weder absolut noch relativ etwas über ihre Position.

Stattdessen enthält der vom Compiler generierte Code Platzhalter für die Positionen der globalen Variablen. Diese werden dann durch tatsächliche Positionen ersetzt, wenn die endgültige Adresse festgelegt wird (traditionell, wenn das Programm verknüpft ist, manchmal jedoch erst, wenn es ausgeführt wird ).

Obwohl es einige CPUs (wie die 6502) gibt, die ohne vorherige Einrichtung direkt auf einen globalen Speicherort zugreifen können, gibt es viele, die dies nicht können. Um beispielsweise auf arm auf eine globale Variable zuzugreifen, muss der Compiler normalerweise zuerst die Adresse der Variablen in ein Register laden, entweder unter Verwendung eines Literalpools oder in neueren Versionen von arm unter Verwendung von movw / movt. Greifen Sie dann mit einem registerrelativen Ladebefehl auf die globale Variable zu.

Dies bedeutet, dass für Variablen außerhalb der Kompilierungseinheit der Zugriff auf mehrere Elemente derselben globalen Struktur wahrscheinlich effizienter ist als der Zugriff auf einzelne globale Variablen.

Um dies zu testen, habe ich den folgenden Code mit ARM gcc 8.2 und -O3 Optimierung in godbolt eingegeben.

  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;
}}
 

Dies führte zu

  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
 

Im Fall von f1 sehen wir, dass der Compiler die Adressen von a und b getrennt von Literalpools lädt (die Adressen in den Literalpools werden später vom Linker ausgefüllt).

Im Fall von f2 muss der Compiler die Adresse der Struktur jedoch nur einmal aus dem Literalpool laden, noch besser, weil er weiß, dass die beiden Variablen im Speicher nebeneinander liegen, und sie mit einem einzigen "Speicher schreiben kannmehrere "Anweisungen anstelle von zwei separaten Speicheranweisungen.

aber von einem Stil-POV ist dies besser oder schlechter als das Einfügen in die Dateien globals.c und / oder globals.h?

IMO, das davon abhängt, ob die Variablen tatsächlich zusammenhängen oder nicht.