Das Geheimnis von #include in C++: <file> vs "file" — Geschwindigkeit und Optimierung

Einleitung: Ein kleines Detail, das Sie Sekunden der Kompilierung kosten kann

Stellen Sie sich vor: Sie schreiben ein C++-Projekt. Die Arbeit läuft, der Code wächst, die Ordner mit Dateien vermehren sich. Und dann tippen Sie wieder #include. Wie gewohnt – in spitzen Klammern? Oder in Anführungszeichen? Und welchen Unterschied macht das eigentlich? Der Compiler ist doch schlau und findet es selbst.

Spoiler: Er wird es finden. Aber nicht immer schnell. Und nicht immer die Datei, die Sie gemeint haben. Die Frage nach dem Unterschied zwischen #include <filename> und #include "filename" ist eine der beliebtesten auf Stack Overflow (Hunderttausende von Aufrufen). Und es geht nicht nur um syntaktischen Zucker. Es geht um Kompilierungsleistung, Kontrolle über Abhängigkeiten und letztendlich um die Qualität Ihres Codes.

In diesem Artikel werden wir nicht nur die Regeln auflisten. Wir werden unter die Haube des Präprozessors schauen, reale Beispiele analysieren und praktische Tipps geben, wie Sie den Build Ihres Projekts beschleunigen können. Los geht's!

Wie funktioniert der Präprozessor? Anatomie der #include-Direktive

Bevor der Compiler Ihren Code sieht, kommt der Präprozessor zum Einsatz. Seine Aufgabe ist es, die "Quelldatei" für die Kompilierung vorzubereiten. Die Direktive #include ist ein Befehl: "Nimm den Inhalt der Datei X und füge ihn genau hier ein, anstelle dieser Zeile."

Klingt einfach. Aber der Teufel steckt, wie immer, im Detail. Und zwar darin, wo der Präprozessor nach dieser Datei X sucht.

Spitze Klammern: #include <filename>

Wenn Sie #include <iostream> schreiben, begibt sich der Präprozessor ausschließlich auf die Suche entlang der standardmäßigen Systempfade. Unter Linux sind das normalerweise /usr/include, /usr/local/include und Pfade, die dem Compiler über das Flag -I (oder /I in Visual Studio) übergeben wurden.

Entscheidender Punkt: Der Präprozessor schaut NICHT in das aktuelle Projektverzeichnis. Nur in die Ordner, die ihm als "System-" oder "Include-Suchpfade" angegeben wurden.

Dies wurde absichtlich so gemacht: um zu verhindern, dass versehentlich eine lokale Datei mit demselben Namen anstelle der Standardbibliothek eingebunden wird.

Doppelte Anführungszeichen: #include "filename"

Bei Anführungszeichen ist die Geschichte komplexer und interessanter. Der C++-Standard (Abschnitt 16.2) sagt: Das Verhalten ist implementierungsabhängig. Aber in der Praxis arbeiten 99% der Compiler (GCC, Clang, MSVC) nach dem gleichen Prinzip:

\n
1. Zuerst Suche in dem Verzeichnis, in dem sich die includierende Datei selbst befindet (normalerweise der aktuelle Ordner mit der Quelldatei).
\n
2. Dann Suche entlang der gleichen Pfade wie für spitze Klammern (System + -I).
\n

Das heißt, #include "myheader.h" überprüft zuerst den Ordner mit Ihrer main.cpp. Gefunden – prima. Nicht gefunden – geht es zur Systemliste.

Ist das nur Wissen oder echte Optimierung?

"Na und?", werden Sie fragen. "Computer sind schnell, welchen Unterschied macht es, wo gesucht wird?"

Es gibt einen Unterschied, und er setzt sich aus zwei Faktoren zusammen: Suchgeschwindigkeit und Klarheit der Absicht.

Faktor 1: Geschwindigkeit der Dateisuche

In einem kleinen Projekt (10-20 Dateien) werden Sie keinen Unterschied bemerken. Aber in einem echten Enterprise-Produkt oder einer Spiel-Engine kann die Anzahl der Includes in die Zehntausende gehen. Jedes Mal, wenn Sie #include "some_system_lib.h" schreiben, verschwendet der Präprozessor zusätzliche Zeit mit der Überprüfung des aktuellen Ordners und aller Unterordner (abhängig von der Implementierung).

Ein Beispiel aus der Praxis: Stellen Sie sich vor, Sie haben ein Projekt mit 10.000 Dateien. 20% davon verwenden Anführungszeichen für Standardbibliotheken. Jedes solche Include führt einen zusätzlichen Systemaufruf stat() oder access() im aktuellen Verzeichnis durch. Das sind Mikrosekunden, aber summiert über das gesamte Projekt – echte Sekunden der Kompilierung.

Die Verwendung von #include <iostream> anstelle von #include "iostream" stellt sicher, dass die Suche sofort bei den Systempfaden beginnt und das lokale Verzeichnis übersprungen wird. Dies gibt