.. in #include
-
Hallo,
gibt es eigentlich gute Argumente für oder gegen .. im Includephfad? Was ist der bessere Stil?
Nehmen wir an, wir haben ein Projekt proj mit zwei Subverzeichnissen foo und bar. Es gibt zwei Header und zwei Implementationsdateien:
proj/foo/foo.H
proj/foo/foo.C
proj/bar/bar.H
proj/bar/bar.CNach der Installation landen die Header in
/usr/include/proj/foo/foo.H
/usr/include/proj/bar/bar.HNun muss zum Beispiel die bar.C die beiden Header includen. Wie macht man das?
Für bar.H:
#include "./bar.H" oder
#include "bar.H" oder
#include <bar.H> oder
#include <proj/bar/bar.H> oder
#include "../bar/bar.H"Für foo.H:
#include "../foo/foo.H" oder
#include "proj/foo/foo.H" oder
#include <proj/foo/foo.H>Meine Favoriten sind
#include "./bar.H" #include "../foo/foo.H"
Das hat aber ein Problem, wenn bar ein symlink ist.
Also, was sind Argumente für oder gegen einen Stil?
-
include <proj/foo/bar.hpp>
das ist imho leserlicher. Außerdem ist die Datei dann nicht mehr Positionsabhängig.
-
Pfade relativ zum Verzeichnis der Datei:
//nehmen wir die Verzeichnishierarchie so an: //proj //+foobar.h //-ordner //-+foo.h //-+datei.h //--foo //--+bar.h //datei.h: #include "bar.h" #include "foo/bar.h" #include "../foobar.h"
Pfade relativ zum Suchpfad:
#include <bar.h> #include <foo/bar.h> #include <../foobar.h>
In diesem fall ist das Verzeichnis ordner in den Suchpfad eingetragen
-
Hi,
ich finde das ist generell Mist!
Warum sollten zwei Verzeichnisse existieren,
ausser wenn es unterschiedliche libs sind?Wenn sich die Verzeichnisstruktur ändert, muss man die Cpp's und ggf. Hpp's
ändern! Das ist doch schlecht.Jockel
-
Hallo,
bei Bibliotheken inkludiere ich immer relativ zu einem Include-Verzeichnis mittels:include <proj/foo/bar.hpp
Grund: Für Bibliotheken lagere ich Include- und Source-Dateien in unterschiedlichen Verzeichnissen und diese include-Technik erlaubt das unabhängige Verschieben der beiden Verzeichnisse ohne Änderung an den Quelldateien. Einfach im Build-Skript die neuen Pfad zum Include-Verzeichnis angeben und fertig.