ich frage mich grad' was der "übliche" Weg ist, Quellcode in Unterverzeichnissen zu gruppieren und weiter wie das ganze dann sauber im Makefile und Sourcecode gehandhabt wird?

Ein Bsp. meines Anliegens:

Verzeichniss | Objekt bzw. Datei
-------------+-----------------------
-------------+-----------------------
/            | Makefile
-------------+-----------------------
/classA      | classA
-------------+-----------------------
/classB      | classB  extends classA
/classB1     | classB1 extends classB
/classB2     | classB2 extends classB
...          |
/classBn     | classBn extends classB
-------------+-----------------------
/classC      | classC  extends classA
/classC1     | classC1 extends classC
/classC2     | classC2 extends classC
...          |
/classCn     | classCn extends classC

Bisher habe ich alle Klassen in ein Verzeichniss gepackt um mit der #include Anweisung keinen Ärger zu bekommen. Wenn ich aber verschachtelte Verzeichnisse verwende muss ich hässliche Verzeichniss-Angaben wie "../../bla" machen.

Eine Idee von mir ist alles in Unterverzeichnisse zu ordnen und die #include Anweisungen zu schreiben als wenn alles in einem Verzeichniss wäre. Das Makefile linkt dann alles in ein temporäres Verzeichniss und wirft den Compiler an.

Was meint ihr?

Gruß, Goran

#include <myapp/foo/bar.hpp>

du gibts deinem compiler einen include pfad an und inkludierst dann nur noch so:

#include <myapp/foo/bar.hpp>

Wäre nicht korrekt:

#include "myapp/foo/bar.hpp"

wenn es sich um Projekt Dateien handelt.

D.h. Dateien in MyApp verwenden:

#include "myapp/foo/bar.hpp"

Und Dateien in "myapp/foo"

#include "bar.hpp"

Das die durch den Compiler angegebenen Verzeichnisse mit durchsucht werden wie bei #include <>, finde ich hier eher ungewollt.

Just my 2 cents.

Goran

Das die durch den Compiler angegebenen Verzeichnisse mit durchsucht werden wie bei #include <>, finde ich hier eher ungewollt.

Das ist aber die Idee dahinter.

Man kann natuerlich die relativen Pfade verwenden - spricht nicht viel dagegen. Ich persönlich finde es aber schöner dem compiler mein source directory als include pfad anzugeben.

um dann eben immer
#include<myapp/foo/bar.hpp>
schreiben zu können ohne darauf achten zu müssen ob die aktuelle datei in myapp/foo oder myapp/baz oder myapp/foo/baz liegt. man kann so auch leichter aehnlich klingende oder doppelte namen haben.

aber technisch kann man natuerlich auch mit "" arbeiten - nur muss man dann immer die aktuelle datei miteinbeziehen wenn man include schreibt...

Man kann natuerlich die relativen Pfade verwenden - spricht nicht viel dagegen. Ich persönlich finde es aber schöner dem compiler mein source directory als include pfad anzugeben.

um dann eben immer
#include<myapp/foo/bar.hpp>
schreiben zu können ohne darauf achten zu müssen ob die aktuelle datei in myapp/foo oder myapp/baz oder myapp/foo/baz liegt. man kann so auch leichter aehnlich klingende oder doppelte namen haben.

Und das finde ich macht die Konfusion in einem Projekt komplet. Welche Datei wiurd denn nun gezogen?
Welchen Sinn macht in der projektorganisation eine Pfadangabe, die nicht existiert?
Zudem wenn ein Common Verzeichnis über mehrere Projeke verwendet wird und eben durch das Zusammenfügen mehrere Libs evtl. auch noch gleiche include Datei Namen entstehen können!

Ich denke es ist Geschmacksache, aber ich versuche #include <> nur dann zu verwenden, wenn ich auch wirklich die include Pfade im C/C++ Compiler im Projektdesign verwende.