Muss ich die Header-Dateien in einem C-Programm kompilieren?

Manchmal sehe ich jemanden, der ein C-Programm wie folgt kompiliert:

gcc -o hello hello.c hello.h

Wie ich weiß, müssen wir nur die Header-Dateien wie folgt in das C-Programm einfügen:

#include "somefile"

und das C-Programm kompilieren: gcc -o hello hello.c.

Wann müssen wir die Header-Dateien kompilieren oder warum?

Zunächst einmal allgemein:

Wenn diese .h Dateien sind in der Tat typische Header-Dateien im C-Stil (im Gegensatz zu etwas völlig anderem, das zufällig mit benannt wird .h -Erweiterung), dann nein, es gibt keinen Grund, diese Header-Dateien unabhängig voneinander zu “kompilieren”. Header-Dateien sollen in Implementierungsdateien aufgenommen und nicht als unabhängige Übersetzungseinheiten in den Compiler eingespeist werden.

Da eine typische Header-Datei normalerweise nur Deklarationen enthält, die in jeder Übersetzungseinheit sicher wiederholt werden können, ist zu erwarten, dass das „Kompilieren“ einer Header-Datei keine schädlichen Folgen hat. Aber gleichzeitig wird es nichts Nützliches erreichen.

Im Grunde Kompilieren hello.h als eigenständige Übersetzungseinheit, die der Erstellung einer degenerierten Einheit entspricht dummy.c Datei bestehend nur aus #include "hello.h" Richtlinie, und diese füttern dummy.c Datei an den Compiler. Es wird kompiliert, aber es wird keinem sinnvollen Zweck dienen.

Zweitens speziell für GCC:

Viele Compiler behandeln Dateien je nach Dateinamenerweiterung unterschiedlich. GCC hat eine Sonderbehandlung für Dateien mit .h -Erweiterung, wenn sie dem Compiler als Befehlszeilenargumente bereitgestellt werden. Anstatt es als reguläre Übersetzungseinheit zu behandeln, erstellt GCC eine vorkompilierter Header Datei dafür .h Datei.

Hier kannst du darüber lesen: http://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html

Das ist also der Grund, den Sie vielleicht sehen .h Dateien direkt in GCC eingespeist werden.

Okay, lassen Sie uns den Unterschied zwischen aktivem und passivem Code verstehen.

Der aktive Code ist die Implementierung von Funktionen, Prozeduren, Methoden, dh die Codeteile, die zu ausführbarem Maschinencode kompiliert werden sollen. Wir speichern es in .c-Dateien und müssen es sicher kompilieren.

Der passive Code wird nicht selbst ausgeführt, sondern musste den verschiedenen Modulen erklären, wie sie miteinander kommunizieren. Normalerweise enthalten .h-Dateien nur Prototypen (Funktionsheader), Strukturen.

Eine Ausnahme bilden Makros, die formal aktive Teile enthalten können, aber Sie sollten verstehen, dass sie in der sehr frühen Phase des Erstellens (Vorverarbeitung) mit einfacher Substitution verwendet werden. Zur Kompilierzeit werden Makros bereits in Ihre .c-Datei eingesetzt.

Eine weitere Ausnahme sind C++-Vorlagen, die in .h-Dateien implementiert werden sollten. Aber hier ist die Geschichte ähnlich wie bei Makros: Sie werden in der frühen Phase (Instanziierung) ersetzt und formal ist jede andere Instanziierung ein anderer Typ.

Abschließend denke ich, wenn die Module richtig gebildet sind, sollten wir die Header-Dateien niemals kompilieren.

In manchen Systemen nennen Versuche, die Assemblierung von vollständig aufgelösten ‘.c’-Dateien zu beschleunigen, die Vorassemblierung von Include-Dateien “Kompilieren von Header-Dateien”. Es handelt sich jedoch um eine Optimierungstechnik, die für die tatsächliche C-Entwicklung nicht erforderlich ist.

Eine solche Technik berechnet im Grunde die Include-Anweisungen und hält einen Cache der abgeflachten Includes. Normalerweise wird die C-Toolchain die enthaltenen Dateien rekursiv ausschneiden und einfügen und dann das gesamte Element an den Compiler weitergeben. Bei einem vorkompilierten Header-Cache prüft die Toolkette, ob sich Eingaben (Definitionen, Header usw.) geändert haben. Wenn nicht, werden die bereits vereinfachten Textdateiausschnitte dem Compiler bereitgestellt.

Solche Systeme sollten die Entwicklung beschleunigen; Viele solcher Systeme waren jedoch ziemlich spröde. Da die Computer immer schneller wurden und sich die Techniken zur Verwaltung des Quellcodes änderten, werden tatsächlich weniger Header-Precompiler im gemeinsamen Projekt verwendet.

Bis Sie tatsächlich eine Kompilierungsoptimierung benötigen, empfehle ich Ihnen dringend, Header vorab zu kompilieren.

Wenn wir die Header-Datei wie folgt einschließen: #include oder #include “header.h”, dann nimmt Ihr Präprozessor sie als Eingabe und fügt die gesamte Datei in den Quellcode ein. Der Präprozessor ersetzt die #include-Direktive durch den Inhalt der angegebenen Datei. Sie können dies durch das Flag -E an GCC überprüfen, das die temporäre Datei .i (Informationsdatei) generiert, oder Sie können speziell das cpp(LINUX)-Modul verwenden, das automatisch vom Compiler-Treiber verwendet wird, wenn wir GCC ausführen. Es wird also tatsächlich zusammen mit Ihrem Quellcode kompiliert, Sie müssen ihn nicht kompilieren.

Ich denke, wir müssen die Head-Datei vorverarbeiten (vielleicht NICHT die Kompilierung aufrufen). Denn nach meinem Verständnis sollte die Head-Datei während der Kompilierphase in der C-Datei enthalten sein. Zum Beispiel haben wir in test.h

typedef enum{
    a,
    b,
    c
}test_t

und in test.c haben wir

void foo()
{
    test_t test;
    ...
}

Ich denke, während der Kompilierung wird der Compiler den Code in der Head-Datei und der C-Datei zusammenfügen und der Code in der Head-Datei wird vorverarbeitet und ersetzt den Code in der C-Datei. In der Zwischenzeit sollten wir den Include-Pfad besser im Makefile definieren.

Sie müssen keine Header-Dateien kompilieren. Es macht eigentlich nichts, also macht es keinen Sinn, es auszuführen. Es ist jedoch eine großartige Möglichkeit, nach Tippfehlern, Fehlern und Fehlern zu suchen, sodass es später einfacher ist.